Today, Alan Cox (alan@lxorguk.ukuu.org.uk) wrote:
# If you are going to allow opendir on a file (which is one fairly sane way
# to handle stream enumeration)
s/sane/hacky/
If you're going to allow directory operations on a file with streams,
things start to look even more confusing than they already are. Would
opendir() fail if you try and open a file with no streams? If not, why
not, and if so, what with? ENOTDIR?
How do you think we explain the differences between files and directories
to new users when files start to have the semantics as directories? Urgh,
no thanks.
I'm all for Linux supporting streams, forks, EAs and
(eventually) structured storage, but doing it in a manner which makes them
appear as something they're not isn't the best way to do it (and would no
doubt in years to come be one of those things that people swear about when
the semantics eventually change to something more sane).
- Files with EAs are not the same as files with streams.
- Files with streams aren't directories.
- EAs and streams are locked to that file, and share the same access
permissions. You move the file or rename the file, the streams follow,
because they are *part of the file*.
- When you open a file, if there is more than one stream, then you open
the default stream.
What Linux needs is a sane API for handling EAs and streams. Turning
streams into separate pseudo-files visible in the same (or some
sub) directory that the 'owning' file lives in is kludgy, to say the
least, and defeats one of the fundamental points of streams (the 'black
box' effect).
Accessing streams via some extension of the namespace (e.g., foo:bar, as
NT does it) is preferable, but not strictly necessary, IMHO, provided a
well thought-out API is provided.
Whether or not EAs are implemented as a specific stream on filesystems
that support it is another issue altogether - and is entirely a filesystem
implementation detail. Other than that specific case, EAs and streams are
not the same thing at all.
Mo.
-- 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:33 EST