Anton Altaparmakov wrote:
>
> Hans,
>
> Thanks a lot for the clarifications! - I think I understand what you mean
> now and agree with you. - A unified namespace is a good thing indeed, so I
> see why you wanted to stick to the directories/files tructures.
>
> There is only one problem left:
>
> On Sat, 28 Oct 2000, Hans Reiser wrote:
> > Anton Altaparmakov wrote:
> > > 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.....
>
> Unfortunately the NTFS filesystem supports directories which contain named
> streams (note: there is no default/unnamed stream allowed, but you can
> have as many named streams as you like).
>
> If you have Windows NT computer at hand just do:
> cd c:\
> c:
> echo "Hello" > \:mygreet
>
> And suddenly your C: drive's root directory has a named stream
> "mygreet" and it contains the data "Hello".
>
> So you can't have an emulator doing this, the FS or better VFS should be
> able to cope with this situation IMHO since there might be other fs'
> which support such strange things, too.
>
> And to make things worse you could also add an EA named mygreet to the
> root directory with contents "Oh dear".
>
> And finally create a file in the root directory called "mygreet" and the
> confusion is complete. )-:
>
> > > 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
>
> See above.
>
> But I agree, it is possible to use /extend_fs_semantics/XYZ/filename for
> variable XYZ (eg. ea, stream, SID, and what not) to cover all possible
> cases or use some equivalent alternative.
>
> > > 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.
>
> Well, having been exposed to NTFS too much I can't help thinking in NTFS
> ways:
>
> named streams are just like files, except they inherit all credentials,
> access times, etc from the main file rather than having their own but they
> are stored just like normal files otherwise. - When you want to access any
> of the named streams you reach the data by going through the
> attributes in the NTFS inode looking for an attribute of type $DATA with
> name equal to the name of the requested named stream. - thus, normal file
> ops feel "natural" here.
Ok, so you understand that we can implement streams as files that inherit their stat
data from the
directory they are in, yes?
>
> EAs are stored differently in that there is only one EA attribute in the
> NTFS inode (you find it the same way as above, i.e. scanning the inode
> attributes for an attribute of type $EA) and once you have found that you
> treat the data contents of the $EA attribute as a linked list of key/value
> pairs and hence if you are retrieving a certain EA you have to scan this
> linked list comparing the name of each EA in the list to the one you are
> looking for. - thus, normal file ops don't feel "natural" here.
>
> Do you see now what I mean? - It is more of a "feel" thing than anything
> else, I have to admit.
Do you see that this feel is the feel of awkardness?
I mean, we can create an optional ordering on a directory (a genuinely useful feature
for unrelated
reasons), and we can let braindead (err, designed for windows:-) ) apps go through the
directory in
order, comparing each filename to what it is looking for, and thus get the same
"feel". Linux apps
can access the same files simply by name and run faster as a result.
>
> > 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.....
>
> Agreed. - In view of that, I would say that even if it feels unnatural to
> me, I would accept to use the file ops for EAs as well. - The NTFS
> driver and userspace can always provide some convenience macros and/or
> functions for accessing the linked EA list.
>
> Using a unified namespace type of access mechanism other NTFS attributes
> could be exposed immediately through the same API which should be a
> bonus as long as access permissions are carefully considered/observed...
>
> > 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.
>
> Ok. having things implemented so differently from e.g. Windows will cause
> some headaches to people trying to port programs from one platform to the
> other but then again the holy penguin probably wouldn't care about that
> anyway... (((-;
>
> Regards,
>
> Anton
>
> --
> Anton Altaparmakov Phone: +44-(0)1223-333541 (lab)
> Christ's College eMail: [EMAIL PROTECTED]
> Cambridge CB2 3BU WWW: http://www-stu.christs.cam.ac.uk/~aia21/
> United Kingdom ICQ: 8561279
It's a good feeling when somebody understands.
Hans
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
