Messages in this thread | | | Date | Fri, 11 Aug 2000 19:38:10 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: NTFS-like streams? |
| |
Date: Fri, 11 Aug 2000 16:48:13 -0400 From: Michael Rothwell <rothwell@holly-springs.nc.us>
None has. There's two different ways of doing it currently; the BeOS way and the NT way. As you said, NT makes a namespace augmentation, using the ":" character to deliniate attribute names from file names. This is called "named streams". BeOS does not do that, but provides special accessor functions instead; this is called "extended attributes." They both accomplish the same goal though: keeping extra data about a file with the file.
This is a very old debate; it's about time we make it an FAQ.
"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".
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. There are far too many file formats (tar, zip, etc.) that will cause the same problem. There are far too many *protocols* (http, ftp, nfsv3, etc.) that also don't know about streams. 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.
Hence, from an application design point of view, there's almost always a better way to do things.
Alexander Viro wrote: > There is a sane and completely portable scheme - use directories. It's > less brittle and will work with the standard tool on normal filesystems. > Why not use it?
Because it's more brittle. There is no reliable way to keep the extra data associated with a file actually with the file. Using directories at best keeps it _near_ the file. Plus, the implementation of "extended attributes" using regular directories would probably be highly application-dependant.
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. For general, application-specific data (i.e., for spreadsheets, personal finance programs, etc.) that's clearly the right approach to use.
It doesn't help the case where you want to anontate a random program with an icon, etc. but in many cases attaching the icon to the file is the wrong thing to do anyway. (a) it doesn't allow a user to attach an icon to a file which he/she doesn't own, and (b) it doesn't solve the problem that each user may want their own specific icon attached to a file --- for example, if the icon has any text in it at all, it will likely need to be internationalized for the user's locale/language.
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 the mod-time on a file, 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. That is, you don't have the Macintosh Mistake to worry about, where it you can't just ftp a file without worrying playing magic binhex games, becausse there isn't critical appplication data stored in "resource forks" which will get dropped by ftp, http, zip, tar, cp, shell redirection, etc., etc., etc.
- Ted
- 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/
| |