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

    > I'm interested in implementing a system that associates
    > meta-data with inodes, and would like to know if it has
    > already been done or is in the works.

    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.


    Urban Widmark wrote:

    > Erm. What is the point?
    > If you read x.bmp do you eventually start reading x.bmp:thumbnail?

    The point is to be able to store and manage extra data about a file
    with the file. On BeOS and NT, if you copy, move, rename, etc. a
    file, the metadata (stream/attribute data) stays with it. The Mac
    uses its streams to store file type information, icon, icon
    position, comments and more. That's all done in a standard way and
    is transparent to applications simply wanting to read the data fork.

    I'm not sure what your question is asking. You don't have to read
    x.bmp:thumbnail if you do not want to. But if you want to view the
    thumbnail, it's there. For instance, on the Mac, you can have a
    comment stored with each file as an extended attribute. Applications
    can choose to use this data if they want, but htye do not have to. It
    simply makes things nicer for the user.


    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.


    Alexander Viro wrote:
    > The main problem is that rename(), unlink(), etc. are too
    > fine-grained for such beasts. It's not that filesutils will barf on
    names.
    > Just suppose that you are saying mv * foo/bar. Shell will substitute
    > the whole whorehouse - filename1:attribute1, filename1:attribute2,
    etc.
    > and in the best case mv will call rename() on each of them (just how
    should
    > we interpret "move the attribute A of file B into directory
    foo/bar"?).
    > In the worst it will try to _copy_ them and then remove the old ones.
    > Moreover, you are going to confuse the hell of VFS and every program
    out
    > there (let alone POSIX, etc.) if rename() on one name will move a
    bunch of
    > other. It just does not happen.

    The whole whorehouse wouldn't be moved, or shell-subsitutited. If you
    had a
    file, "myfile", which had three streams named "1", "2" and "3", on a
    streams-
    aware filesystem, all you see in "ls" is "myfile", not "myfile:1",
    "myfile:2",
    etc. And to copy or move the file, you just "copy myfile" and the
    streams go
    with it.

    Linux can actually be equipped with both BeOS-type nad NT-like systems
    for
    accessing named streams/extended attributes. A filesystem can tell the
    VFS
    taht it supports named streams. Otherwise, named streams are not
    supported.
    This is similar to NTFS vs FAT on Windows NT. If you copy a file with
    streams
    from and NTFS volume to a FAT volume, the streams are thrown away. There
    is no
    attempt made to support streams on a filesystem that does not support
    them.

    Similarly, an enhanced Linux VFS can support or not support streams,
    depending
    on the capabilities of the underlying filesystem. The Macintosh actually
    makes
    and attempt to preserve extended attributes on non-HFS filesystems
    through
    "AppleDouble" and "AppleSingle" schemes. While that is interesting, I
    prefer the
    cleaner NT way of dealing with it -- don't kludge extra features onto
    that don't support them.

    Granted, there will still be issues with userspace tools like cp. Rm and
    mv
    will not have an issue, unless mv is moving across volumes. Cp and mv
    will
    have to enumerate and copy all streams. Rm will not need to enumerate
    streams;
    if you delete a file with streams, all the streams go with it.

    On filesystems that support fast indexing -- JFS, XFS, Reiser -- streams
    can be
    used as in BeOS to provide indexing capabilities. BeOS email
    applications, for
    instance, use extended attributes to store information about a message
    -- the
    subject, sender, etc. This allows any application to look up email
    messages by
    those criteria simply by reading the attributes, rather than parsing
    mail
    headers.

    -Michael


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