lkml.org 
[lkml]   [2000]   [Aug]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: NTFS-like streams?
    Christer Weinigel wrote:

    > So what is the sane way? There are three conflicting requirements for
    > NTFS-like streams handling:
    >
    > 1. Don't break any existing tools, everything must behave exactly as
    > it does today. tar must be able to make a complete backup.
    >
    > 2. Should allow old tools to work on the alternate streams (i.e.
    > xv file/thumbnail.xpm).
    >
    > 3. Should not pollute the filesystem with extra files such as
    > .AppleDouble, .fork, foo:resources or foo#tar/altstream.


    Tar can be updated; the format (AFAIK) already supports
    named streams/EAs, but the tools do not always. What's the point
    in making apps written before streams existed work with streams
    unmodified? It's like trying to make stereo sound work on a mono
    radio -- the mono radio is not aware of two sound channels and
    reproduces only a mono signal. Ditto with color TV -- it will
    display on black and white TVs, but without color -- without the
    extra data channels that create the color image.

    Backwards-compatible does not have to mean "the same as."

    -M

    > The "files as directories" way is a big deviation from how things work
    > today, suddenly one can do opendir/readdir on a file

    Files with streams are not directories. I would not expect
    readdir() to work on them. There would have to be a different
    enumerator function.


    > Any comments, I've just tried to do a brain dump to see if anybody
    > agrees with me or if we're still talking past each other.

    :)

    > Are there any other ways of doing this?

    Well, the filesystem could register "I support streams" and/or
    "I support EAs" with the VFS (by providing function pointers
    or something), _and_ provide its preferred namespace
    augmentation, ":" for NTFS, for example. After all, ":" is
    not a legal file or pathname character on NTFS.

    I'm not sure that second part is cleaner than Linus'
    straightforward "/dir/file/stream" idea, though. It
    looks like it might break the "consistency" we're
    looking for, whereas Linus' idea will not.

    On a side note, how many things will _break_ if ":"
    is used? I.e., /dir/file:stream ?

    -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/

    \
     
     \ /
      Last update: 2005-03-22 13:58    [W:3.731 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site