[lkml]   [2000]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: NTFS-like streams?
    "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.


    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.025 / U:11.948 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site