[lkml]   [2004]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: silent semantic changes with reiser4
    Matt Mackall wrote:

    >What it breaks is the concept of a file. In ways that are ill-defined,
    >not portable, hard to work with, and needlessly complex. Along the
    >way, it breaks every single application that ever thought it knew what
    >a file was.
    >Progress? No, this has been done before. Various dead operating
    >systems have done it or similar and regretted it. Most recently MacOS,
    >which jumped through major hurdles to begin purging themselves of
    >resource forks when they went to OS X. They're still there, but
    >heavily deprecated.
    >>cp, grep, cat, and tar will continue to work just fine on files with
    >>multiple streams.
    >Find some silly person with an iBook and open a shell on OS X. Use cp
    >to copy a file with a resource fork. Oh look, the Finder has no idea
    >what the new file is, even though it looks exactly identical in the
    >shell. Isn't that _wonderful_?
    It is what I'd expect. Now, use cp -R to copy the file
    _with its directory_, and see if that fares better. If not - bad
    implementation of fs and/or cp. The way I see file-as -directory
    is that _file_ operations (like the reads issued by cat) only
    work on the file part. You want the directory part? Use
    directory operations such as those "cp -R" use.

    >Now try cat < a > b on a file with a
    >fork. How is that ever going to work?
    It is going to copy the _file_ part, of course. I wouldn't
    expect anything else - "cat" doesn't deal with directories.

    This also raise the question of when to use file-as-directory.
    A usage where you need everything to follow the file, even
    when using "cat" calls out for an application that puts everything
    into one file. Directory-as-file is the wrong tool for that job, so don't
    worry about such problems.

    Sticking thumbnails in a file-as-dir is another story though. Move the
    file (with "mv a b", not "cat a>b;rm a") moves the image file _and_ the
    thumbnail. No time wasted on regenerating thumbnails, no disk space
    or cleanup time wasted on dangling thumbs. Use the image file
    for its intended purposes (view it, mail it off, serve it on the web,
    edit it, print it) and the thumbnail doesn't get in the way
    because it isn't embedded in the file format. Embedding it
    in the file might work for jpeg which support generic embedded data,
    it surely won't work for every image format out there.

    This is my idea of how file-as-directory should work.

    Helge Hafting

    Helge Hafting

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:05    [W:0.023 / U:24.844 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site