Messages in this thread | | | Date | Sun, 13 Aug 2000 00:30:48 +0100 (GMT) | From | Mo McKinlay <> | Subject | Re: NTFS-like streams? |
| |
For what it's worth, my list of semantics for EAs/forks (NOT structured storage. *please* note the difference):
- EAs can vanish. Anything using them must expect this to happen.
- EAs are not heirachical - a file can have EAs associated with it, but an EA cannot have more EAs associated with that.
- Files with associated EAs look like files. stat() should return a S_COMPLEX, or something, but to the user, a file is still a file.
- Being able to access EAs using a specific naming techinque (such as file/EA-name, or file:EA-name) would be useful (and probably the most sensible way of going about things)
- A file+EAs is not a directory. Ideally, opendir(file) would fail, as it does now (and an additional call to open the file for enumerating the EAs should be added, although there's no reason why it couldn't return a DIR * instead of some redudant new type)
- EAs can be useful, even where the OS wasn't built from the ground up to support them (because of their 'optional' nature).
- Access permissions of EAs could either inherit totally from the file associated with them. Alternatively, one could specify an alternative (slightly more complex) way of doing it:
* You cannot write to an EA unless you can write to the associated file. * You can read an EA if you can read the directory containing the file. (So you can get the icon for a file, even if you can't actually get the file itself - neater from a user perspective). * You cannot remove/rename an EA unless you can write to the associated file. * You cannot list EAs unless you can read the file (not sure about the point of this one, but it seems logical).
Everyone else can decide on whether EAs could ever be executable. Although I could see the merit of attaching a special wrapper shell-script around a program, and storing it as an EA associated with the program's executable, I'm not sure it wouldn't just complicate matters horribly (and confuse users).
On the other hand, for structured storage:
- A file is a directory is a file. The difference is the attribute and how that makes things appear to the user. The whole thing is heirachical, though (i.e., sub-files have the same semantics as files).
- Nothing's expected to have to cope with sub-files vanishing at random (no more than they're expected to cope with a user doing 'rm directory/file' these days)
- EAs could be implemented as a sub-file using structured storage, but not the other way around - and even if they were, this is an implementation detail that should *never* be relied on.
- Structured storage looses usefulness on an OS not built for it (Anybody remember Microsoft's plans for Cairo, aka Windows 2000, and the Object Filesystem they were going to implement?), because applications taking advantage of it loose portability. Wheras EAs can be enabled/disabled at compile time without massive losses in functionality, the the same doesn't really apply to SS, where if you're going to use it, you go the whole hog or not at all.
I'll shut up now. :)
-- Mo McKinlay Chief Software Architect inter/open Labs ------------------------------------------------------------------------- GnuPG Key: pub 1024D/76A275F9 2000-07-22 Mo McKinlay <mmckinlay@gnu.org>
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |