# > - 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.
# > - 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..
# > - 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..
#
# > - 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??
Point well made.
# > * 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.
-- 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/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:30 EST