lkml.org 
[lkml]   [2004]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: silent semantic changes with reiser4


    On Thu, 26 Aug 2004, Rik van Riel wrote:
    >
    > Thinking about it some more, how would file managers and file chosers
    > handle this situation ?

    The same way they already handle it on other platforms that support it? By
    taking advantage of it..

    People literally use this for icon and preview information, so some of the
    stuff shows up very much in file managers. And I'd assume that a normal
    double-click would just open the main file, and you can right-click for
    management information, including opening the file.

    If you want an entity that acts as a directory, you create a directory.

    Directories don't go away - you still have S_ISDIR() and S_ISREG(), and
    they still return information. A file that has associated information is
    still a _file_, and people should treat it that way, it's just that it
    also has a list of named sub-streams. You can open it as a directory, but
    the stat information clearly says it is a file, and the "directory" view
    is very much associated with _that_ file.

    I definitely don't think you want the file manager to act as if a named
    stream is exactly the same as a stand-alone file. They have all the same
    operations, but there's no question that there are differences too.
    Especially on a conceptual level - but for most filesystems there are
    likely real technical differences too.

    For example, it's likely that most filesystems would _not_ allow linking
    of a named stream anywhere else. And you might not be able to change the
    permissions or date on the named stream either, since it may or may not
    have a separate date/permission thing from the container.

    So don't believe that just because the named streams are _named_ like real
    files, that they suddenly have any existence beyond the container that
    they are part of.

    There may be other limitations too - again depending on how the filesystem
    actually implements named streams. It might not support more than one
    level of naming, for example - so you might not be able to create a
    directory structure within the named streams, for example.

    In short: the fact that the VFS layer exposes the _capability_ to see the
    named streams as a full POSIX filesystem of its own does _not_ mean that
    the low-level filesystem necessarily allows the full possible semantics.
    So you shouldn't design your apps that know about named streams to think
    they are normal directories.

    The directory thing is just a very powerful naming scheme, and one that
    fits into the existing UNIX model.

    > Do we really want to have a file paradigm that's different
    > from the other OSes out there ?

    Different from what other OSes?

    Last I looked, Windows, Solaris, and OSX all supported named streams. What
    other OS's are out there that you care about?

    In other words, this is _not_ a different paradigm from what others do.
    The discussion is whether we want to implement it at all, and more
    importantly about syntactic issues (ie we clearly already implement
    extended attributes, just with a much more limited syntactic power).

    We don't have to go all the way. Solaris has "openat()", which is kind of
    a half-way there - not really directly available in the same namespace,
    but at least the result is available as a real file interface (as opposed
    to the Linux "xattr" interfaces that are _totally_ special-cased system
    calls).

    In other words - the paradigm is already there. It's just that currently
    it's pretty much unusable under Linux, because it requires so much
    specialized knowledge that it's not worth it to modify existing apps. And
    the interfaces are really very limited, so even if you _do_ end up using
    the specialized Linux interfaces, you can't actually do a lot of what you
    might want to do.

    Linus
    -
    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: 2009-11-18 23:46    [W:0.049 / U:151.052 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site