[lkml]   [2000]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: NTFS-like streams?
   Date: 	Fri, 11 Aug 2000 16:48:13 -0400
From: Michael Rothwell <>

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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:58    [W:0.547 / U:0.480 seconds]
©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site