[lkml]   [2000]   [Aug]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: NTFS-like streams?

    # Only if we're going to actually USE the data. Otherwise, mtools like
    # utilities for when we have to fiddle with this data for the other OS's
    # benefit (archiving it, etc) make about as much sense to me.

    Okay, so...the filesystem's mounted, but to back it up you've got to use
    some specialised utility? You may as well not mount it in the first place,
    and just use utilties like mtools throughout.

    Now, to be honest, I don't really care what the desktops do. What I'm
    interested in is a generic interface for accessing this data, if it's
    there - be it a resource fork, a stream, EAs, or whatever. What the
    desktops decide to do with that is up to Miguel, et al.

    Now, the next logical step is to support this as one of the standard
    features of the OS. We can already read them from other filesystems, so
    why not our own de facto standard? And of course, if you're going to read
    them, you want to be able to write them.

    From there comes the decision of whether you support EAs, forks,
    streams, or full-fledged structured storage, but that's down to the
    individual filesystem. If the interface is already there to handle them,
    it doesn't matter.

    How would applications use them? Ultimately, I don't know. For GUIs,
    EAs/small ``unreliable'' forks could be useful. Same applies to web
    servers (storing MIME types as EAs to override the default would be
    mightily handy). Streams and structured storage are a different kettle of
    fish. I could think of a million and one uses for *those* (do the words
    'composite document' mean anything to anybody? :>).

    The ideas tarfs/rpmfs/cpiofs/whateverfs are related issues, and come
    under the 'cool' heading, but don't really bear directly on this.

    [As a belated reply: System-wide default icons? Hell, yes. Installed by
    'make install', and then can be overriden by the file owner. Personally,
    I don't see what the issue is, most icons on a KDE or GNOME desktop are
    links, which have their own icon storage space anyway. If you're putting
    an actual executable on a desktop that you want a custom icon for, the
    chances are pretty high that you own the file in the first place]

    Mo McKinlay Chief Software Architect inter/open Labs
    GnuPG Key: pub 1024D/76A275F9 2000-07-22 Mo McKinlay <>

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