lkml.org 
[lkml]   [2004]   [Sep]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    Subjectfile-as-dir vs. dir? (was Re: silent semantic changes with reiser4)
    (Apologies for beating on a dead horse here...)

    I seems like one confusion here is that everyone has a different idea of
    what the semantics we're talking about are. I see two main ones:

    Hans's: A file, a directory, and an attribute are functionally
    equivalent (except for S_ISxxx and hardlinks). That is, /usr/bin/metas
    makes sense, and it's not talking about a program called metas. This
    also means that /foo/metas/metas might exist and needs dealing with.

    Linus's (I think): A directory is just a directory (no attributes and
    no read()able data). A file can contain attributes, where attributes
    can be "file" attributes or "directory" attributes. That is, a file is
    also a subtree with posix-like semantics (except for hardlink stuff).
    So doing "touch /tmp/foo; cat /tmp/foo/metas" fails, rather than doing
    something that's probably useless. "touch /tmp/foo; touch /tmp/foo/bar;
    touch /tmp/foo/bar/baz" fails on the last touch because bar is a file
    attribute and recursive magic is disallowed.

    Which one are we talking about?

    FWIW, I like the latter version a lot better, as it removes a lot of
    ambiguity. If I see a path like /tmp/foo/metas/uid, it is either a uid
    attribute (i.e. writing it has security implications) or it is a
    standard file (i.e. writing it just writes it). But _I can tell which
    one_ by fstat()ing /tmp/foo! If it's a directory, than I have either a
    named stream called uid or a genuine file called uid (and I can tell
    which by fstat()ing /tmp/foo/metas), but if it's a file then I have the
    magic uid. And I'm guaranteed that there's no other funny business,
    because /tmp/foo is a "file with a subtree," which means that it's not
    an attribute. This way I know exactly what I'm dealing with.

    As an added bonus, we could have O_NOMETAS which means that "files" may
    not be traversed. Then someone who wants to make sure they get a real
    file can do it. If recursive files-as-dirs were allowed, that might not
    do quite what the caller expected. If you really wanted a directory
    with some data attached, but it in dir/.mystuff, because that's probably
    what you meant, and any existing tool will do exactly the right thing
    with it.

    In the former version, AFAIK, I have a mess. In UNIX, a path is a path.
    It's trivial to understand and there's no funny business parsing it.
    But now a path has a slippery meaning where the token "metas" could be a
    plain old token or it could be magic or it could be magic some other
    way. The security implications and the possbility for something to
    break horribly are scary.

    --Andy
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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