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.
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.
> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
