On Sun, 13 Aug 2000, Mo McKinlay wrote:
> For what it's worth, my list of semantics for EAs/forks (NOT structured
> storage. *please* note the difference):
Is structured storage really a kernel issue? I'd have said the kernel
should treat such files as normal files, then userspace is responsible for
handling the contents.
> - 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.
Yep. ==> EA's are *NOT* directory-like in any way.
> - 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.
Yep. Not sure we need S_COMPLEX - with my solution, the existence of EAs
is obvious without any API changes.
> - 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)
file:EA-name, yes. file/EA-name, no - they are NOT directories, and
shouldn't try to look like one. That way lies breakage, surprises and
nastiness.
> - 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)
No need for a new call: just "ls file:*" to list the EA's attached to
"file". opendir() should certainly fail - it's not a directory in any way.
> - EAs can be useful, even where the OS wasn't built from the ground up to
> support them (because of their 'optional' nature).
Yep. My approach has the advantage you can get "EA's" via ext2 etc without
any change in API - cp WILL copy the EA's attached to a file, making them
into files in their own right. Copy the files back to NTFS, they revert to
being EAs.
> - Access permissions of EAs could either inherit totally from the file
> associated with them.
I'd go with that. That's how NTFS does it, too.
> 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.
Yep.
> * 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).
Hrmm... Supposing the EA is the thumbnail for an image? If you aren't
allowed to read the image itself, do you want the thumbnail readable??
> * You cannot remove/rename an EA unless you can write to the associated
> file.
Hrm. Either that, or handle it in the same way as for deleting the file
itself: write permissions to the parent directory.
> * You cannot list EAs unless you can read the file (not sure about the
> point of this one, but it seems logical).
Ehm... hang on. If I have read access to a directory, and no access to a
file in that directory, I should be able to READ the EAs of that file -
but not LIST them?!?!
> 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).
I'd just treat the EA's like the file's main data attribute. On an FS
level, all the attributes are equal - why treat them differently at
user-level?
James.
-
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/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:29 EST