[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.028 / U:63.188 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site