"Theodore Y. Ts'o" wrote:
> This is a very old debate; it's about time we make it an FAQ.
Please do, then; a lot of us probably don't know this history
of this particular debate (please don't flame me).
> "Named streams" and "extended attributes" are quite different. One
> allows you to seek around, and read write parts of it, as a stream. The
> other reuiqres that get or set the entire "extended attribute" all at
> once; there is also usually some kind of size limitation with an
> "extended attribute".
But extended attributes can be implemented using
named streams. This is, in fact, what Services
for Macintosh does on NT/2000, and what MacOSX will
be doing. BeOS provides extended attributes only.
> In general, I tend to be very skeptical that using such things is a good
> idea. There are far too many programs (cp, emacs, vi, shell scripts
> that use pipes and redirection to rewrite files, etc.) that will cause
> the extra data to get lost.
Could you explain?
> There are far too many file formats (tar,
> zip, etc.) that will cause the same problem.
The important data is almost always the main fork.
The extended attributes are just that -- attributes.
Not the main data. As far as tar is concerned, it
will work just fine on a filesystem that supports
streams; for the default streams. If you want to
save the extended attributes, use PAX. Attributes
are a convenience.
> There are far too many *protocols* (http, ftp,
> nfsv3, etc.) that also don't know about streams.
So they transfer the data in the default streams and
work the same way they do now. Apache could still use
streams, though -- store a custom mime type and/or icon
as a stream with a file. So if you have a ".pdf" file
that isn't a "Portable DOcument Format" file, but one
of those microsoft installer-thingies, you can note
the exception if you want. Or if you have a ".asp"
file that is actually a Photoshop file and not an
Active Server Page, ditto. If you want Apache to be
able to provide custom icons and descriptions for files
in generated directory indexes, that info can be stored
as attributes or streams. But the real file data --
which is all Apache will transfer -- is all people get
when they download the file. And probably all they
will expect.
> This was made most obvious on the Apple Macintosh, where you
> had to use ugly tools like binhex whenever you tried moving a file from
> a Macintosh to some other platform (like an FTP server) lest you make
> data file or an executable useless because you managed to lose one of
> its resource forks.
The "Macintosh Mistake," as you call it, was not providing
extended attributes, but putting actual parts of the
applications in there. Old Mac apps actually store code
fragments, menu text, etc. in the resource fork, which was
a way to provide demand paging on the cheap for those 512K
macs. The bits of the resource fork that are not used for
that -- such as extra type and creator information, thumbnails,
comments, icons, etc -- is useful, but not vital to the file,
and not a "mistake."
> Hence, from an application design point of view, there's almost always a
> better way to do things.
Better how?
> Because of the above problems, using extended data is usually at *least*
> as brittle. The right answer in many instances is to make a easy-to-use
> *user* *library* that allows applications to have the functionality of
> being able to easily store multiple resource forks, but which looks to
> the system like a single file.
Like the Windows Registry? Or what I was suggesting
earlier -- BeOS-type accessor functions allowing
access to extended attributes for a file?
> Now, there is a need for system-specific extended attributes. These are
> attributes which are used by the system, and in many cases can't be set
> by an unprivileged user, even on files that he/she owns. For example,
> ACL's, mandatory access control labels, DMAPI data, etc. all need to
> store metadata associated with a file. However, the difference here is
> that there's an explicit system API which is used to set the attribute
> information. Also, it's very clear that this data is METAdata.
Like a very limited, less useful version of the BeOS
extended attributes?
> while some applications or protocols may
> copy/preserve the some or all of the metadata, it isn't a disaster if
> the metadata isn't copied.
Which is what I've been saying.
-M
-
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:26 EST