On Sun, 13 Aug 2000, Mo McKinlay wrote:
>
> # > - 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.
>
> Yes..which isn't necessarily a good thing. For hackers, it's obvious what
> it is, for end-(l)users, it's not.
For end-users, the extra streams probably won't be visible through
whatever front end they are using. Think .files, for example.
> # > - 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.
>
> So, in order to find out if a file has any EAs, you need to walk the
> directory entries of the file's parent? Consider a directory with 2000
> images, each of which has 4 EAs.. that's incredibly slow compared to
> walking the list of 4 EAs associated with the file itself..
It's a nice simple approach which doesn't break everything. The
alternative you seem to be proposing breaks just about everything which
touches files...
Adding a "list streams of this file" API call to VFS would be nice. Better
still, a nice generic "list all files of this variety" facility... It's
not essential, though.
> # > - 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.
>
> Uh..cp will...if the user knows about them, and that they're supposed to
> copy them when they copy the file (I'm thinking ext2 -> ext2, here). That
> means the user has to know all about EAs and what they are...the nice
> thing about EAs is that the user doesn't see them unless they actually
> want to, and the association is managed automatically - your system breaks
> that quite effectively..
Not really. What precisely ARE EA's, from the user's perspective? They
will look and work a lot like other files, in most cases. Copying the
directory will work as expected. Deleting the directory, too. OK, a simple
"cp file /tmp/" will miss off the EA's, unless you're using an EA-aware
version of cp - but my approach does avoid data-loss, unlike all the
others I've seen mentioned here.
> # > * 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.
>
> Er. Hold on. You can't write to the file itself, but you can delete all of
> it's EAs? That doesn't sound too pretty, to me.
That's how Unix works. You have write access to the parent directory, you
can delete the file. If you can delete "the file", surely you can also
delete the EAs attached to it?
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:30 EST