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


    On Sat, 12 Aug 2000, Theodore Y. Ts'o wrote:
    >
    > This also brings up all sorts of *entertaining* security semantics
    > questions, which were never an issue on OS/2 and Macontish since they
    > didn't have user security.....
    >
    > When are you allowed to create a fork inside a file to which you may not
    > own? Who gets charged the quota on forks that are created when you
    > don't own them?

    I don't think you realize something.

    You argue about resource forks as some abstract interface.

    And a lot of other people are arguing about resource forks as a hard, cold
    reality of existing filesystems.

    > If the answer is that "it works just like creating a file in a
    > directory", then after a point, what *is* the difference of having
    > "resource forks"?

    The difference is simple: they are a fact of life in the OS/2, Mac and NT
    world. They are NOT directories. They will never _be_ directories. And
    stupid hacks like LD_PRELOAD etc completely miss the point.

    The point is not to make a UNIX filesystem look like a resource fork.

    The point is to be able to access resource forks in a way that is
    compatible with UNIX filesystem semantics.

    Maybe the "compatible with UNIX filesystem semantics" thing is not going
    to be a 100% compatibility. After all, NFS certainly doesn't follow some
    fairly basic UNIX rules. But that doesn't mean that NFS is unusable.

    Similarly, with resource forks you almost certainly cannot do a "chown()"
    on a fork. Live with it. It's how the filesystem works.

    Similarly, resource forks are almost certainly not going to allow multiple
    levels: it's not a recursive directory-structure, it's a single level (no,
    it doesn't _have_ to be a single level, but I think it is in existing
    filesystems that support the notion).

    The best we can do is to have _sane_ semantics for supporting such
    filesystems. Sane and usable. Things like "fd_open()" make sense even
    without resource forks - it's kind of a private extension of the notion of
    "current working directory", after all.

    : If we're just treating a "resource fork" as a
    > directory that also contains data, that's actually not that hard. In
    > fact, you could probably do it as a LD_PRELOAD, or as a libc hack. That
    > is:

    You miss the point. Ext2 doesn't have resource forks. End of story.
    There's no point in trying to force them upon it.

    Maybe in the future, if we support resource forks on other filesystems
    sufficiently well, and people end up thinking that it's a reall yneat
    feature, we'll have an ext4 that _does_ to resource forks. Who knows?

    But other filesystems _do_ have resource forks. LD_PRELOAD is pointless.

    This is not a theoretical excercise about "do we want resource forks?".

    This is not a discussion about "are resource forks a good idea?". The fact
    is, they exist.

    This is a practical matter of "how do we sanely export non-UNIX semantics
    of other systems filesystems to UNIX programs".

    Linus


    -
    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:4.780 / U:0.312 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site