Anton Altaparmakov wrote:
>
> Hans,
>
> At 18:30 28/10/2000, Hans Reiser wrote:
> >Anton Altaparmakov wrote:
> > > You can't possibly have both using the same API since you would then get
> > > name collision on filesystems where both named streams and EAs are
> > > supported. (And I haven't even mentioned EAs and named streams attached to
> > > actual _real_ directories yet.)
> >
> >filename/atomic/1
> >filename/1
> >
> >no collision here, and SAMBA or whatever can make filename/1 look like
> >filename:1 or whatever you
> >want.
>
> What about the case where in your example "filename" is a directory? - How
> do you propose to handle that there might be a directory called atomic
> inside directory filename and there might be a file with the name 1 inside
> both directories (filename and filename/atomic) and at the same time the
> named stream 1 exists attached to the directory filename and the EA 1
> exists as well?
Name space collisions (reserved keywords) are a problem in every computer language,
and most of them
provide escape mechanisms to avoid them. We are no different. If we cleanly solve
the reserved
keywords problem in VFS once though, it can then free us to do lots of things over
time.
There are a great variety of ways to solve reserved keywords problems. One of them
(obviously not
one to use, but it should make things clear as an example) is:
/extended_fs_semantics/filename/atomic/1 refers to atomic access to the attribute "1"
of filename,
and filename/atomic refers to the directory.
Another is:
/extended_fs_semantics/atomic/filename/1 refers to atomic access to the attribute "1"
of filename,
and filename/atomic refers to the directory.
If the desire is that atomic shall have meaning for every file in the filesystem then
I think
/extended_fs_semantics/atomic/filename/1 is the best answer. If the desire is to
implement atomic
via plugins that vary from directory to directory then I filename/atomic/1 is the
best, but in this
case I think it is not what is wanted.
>
> Given above scenario:
>
> How would you distinguish the file filename/1 from the named stream filename/1?
I wouldn't, they are the same thing. If you need to emulate some filesystem which
needs to
distinguish them, then I would have the emulator (SAMBA?) call them
filename/1
vs.
filename/stream/1 or /extend_fs_semantics/ea/filename/1
except that I don't know of any filesystem which allows a directory to be a file and
has streams so
I think this is a non-issue.....
>
> And how would you distinguish file filename/atomic/1 from EA filename/atomic/1
I wouldn't, unless emulating another (purely hypothetical so far as I know) filesystem
which has
both files that are directories and extended attributes, in which case I would use
filename/ea/1, or
/extend_fs_semantics/ea/filename/1
>
> In both cases the string looks the same to me... and I don't see how this
> would work.
>
> Also if EAs were to be implemented as extended files/directories, do you
> then suggest to use file/directory operations to work with them? (i.e.
> open, read, write, close). - If yes, I would think that this is inferior to
> the current API proposal where you have direct EA operations (ATR_*). - As
> other people have said EAs are more like environment variables than
Please say more, I am ignorant on how they are like environmental variables, and I
don't want to
dismiss what you say without trying to understand the motivation for it.
I will note though that I feel environmental variables should be accessible via the
OS's centralized
namespace..... anybody remember whether the plan 9 guys did that already, I think
they did.....
> anything else and the API should be consistent with that. - Also how would
> you handle operations on several/all EAs at once? - It would not seem
> possible to do any more if file ops are used? - Or have I misunderstood
> your proposal?
Multiple assignments are separated by semi-colons.
To access two non-stream files (extended attributes), and one stream in one system
call, use the
following:
/process/range/(U,V)<=/filename/1;/process/range/(X,Y)<=/filename/2;/process/range/buffer/(buffer_start,buffer_end,bytes_written)<=/filename/3
>
> Regards,
What it gets right down to is, if you make the effort, you can find ways to add
features to files
rather than fracturing the namespace by creating new things that are not files. You
just have to
have a commitment to purity in design, and you can do it.
On the other hand, if you want to do some hack for perfectly reasonable desires to
avoid doing
anything more than the FS you are copying from some other OS does, why not keep the
hack out of VFS
and
just go directly to user space with your own system call for your FS? I think we
should encourage
people not to use ioctl() for this, as it is just ugly to do so. I wouldn't object to
an
fs_specific("FSNAME", char * command, int command_length ) call.
What I object to is adding it the the VFS in a way that encourages its use for
filesystems
generally, as it is deeply wrong to add things that are like but aren't files and
can't be accessed
as files when you could enrich the functionality of files instead.
Hans
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
