[lkml]   [1999]   [Jun]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: I discussed reading directories as files with jra, Stallman, and loic
    Linus Torvalds wrote:

    > In article <m10vnlI-003VuJC@reiser>, root <> wrote:
    > >
    > >I convinced him that directories can do this, and do it cleaner than
    > >that MS crud they use as an FS model. The directories need a few
    > >features added though.
    > >
    > >First, they need to be able to have a file that when you read them they
    > >resolve to. That is, inside the directory there is one file that when
    > >you open (dirname) you get a file descriptor pointing to
    > >dirname/default. Now please note that dirname/default can be a symlink,
    > >a hard link (presumably to a file within the same directory), it can be
    > >all sorts of things. It can also be called something like "....", or
    > >even "". I have to think some about which I like.
    > Note that the Linux VFS layer was pretty much _designed_ with something
    > like this in mind. From very early on, I decided that the VFS layer
    > should not make too much of a distinction between a directory and a
    > regular file: both have "lookup" properties, and both have "read"
    > properties.
    > Some of that has been corrupted over time, and some of it was never done
    > because nobody actually used it - so there's a few places where the VFS
    > layer does things like "if (!S_ISDIR(d_inode->i_imode))" etc and thus
    > "knows" about the difference between a directory and a regular file, but
    > that was never really meant to be a design goal, and I'd be happy to try
    > to clean it up.
    > So basically it all should be doable today: if a low-level filesystem
    > wants to export directories both as regular files and as pathname
    > components, it can be done. The low-level FS can look at the
    > O_DIRECTORY flag to know whether somebody wants to read the thing as a
    > directory or not (ie "readdir()" obviously opens the directory, while
    > normal operations open the default file), and it should all work pretty
    > much today.
    > It's going to confuse a lot of UNIX applications, but at the same time a
    > reasonable number of them won't ever really have to know.
    > >Next files need to be able to inherit stat data, so that a file can
    > >share its modification time with its parent directory, so that modifying
    > >the file changes the mod time on the directory.
    > I don't think that is true. I think the directory and the file should be
    > considered separate, it's just that "lookup()" can find one or the other
    > depending on use..
    > So I think it should be considered a _naming_ issue, and not much else.
    > >Finally, you need a new file type flag indicating that it is both a file
    > >and a directory.
    > Not necessarily. Just open it with O_DIRECTORY (or with a slash at the
    > end) and it gets opened as a directory, otherwise it gets opened as the
    > file. Works today, and is the most transparent option anyway.
    > Things like "tar" etc probably need to be taught about how to see
    > distinctions like that, and we may want to have other ways of accessing
    > the information, but I don't think we _have_ to have them.
    > Linus

    Seems to me that this proposal is a simplified, and less capable form, of my
    previous proposal
    for a "binder" extension. A binder being a file that contains an internal
    directory of addressable
    files (or objects). To reduce overhead, I proposed using two bits of file
    flags to indicate that an
    entry has not yet been checked as a potential binder; is definitely not a
    binder so VFS can avoid
    extra processing; and an entry is definitely a binder so VFS needs some
    recursive processing
    (originally I had two variations of this).

    All system calls that operate on directories see a binder as a directory. All
    system calls that
    operate on files see a binder as a file. (I have a preliminary map of calls
    around here and only
    a minimum number of calls are ambiguous.) Any of the rare special
    applications that need to
    be aware of binder structure would have a user space library of special calls
    (that are already
    fully present in VFS). No existing applications are impacted at all -
    including tar which
    could easily use the binder as a file or its contents. (Content use by tar
    would lose some
    type information - see below).

    Instead of a 'default' entry, I proposed the use of a file name map that
    permitted all accesses
    within a binder to be re-directed. This was intended to allow applications to
    be placed in a
    binder along with its resources.

    The original message mentions Mac Forks. Mac files have a resource and a data
    fork. Think of
    a binder as a Mac style file with any number of forks! Each fork is named by
    its internal directory
    entry name. And we allow nested binders in binders just like any file system.

    I originally suggested a two phased implementation with the first phase using
    actual fs
    directories to emulate a complete binder implementation. As I thought about
    it further, this
    is really not satisfactory as one goal was to have complete (mime-like) type
    and format
    information for each entry (object) in a binder. To store this additional
    file stat information
    nearly mandates that binders be implemented as VFS files with meta-object
    handling added
    for binders. Applications that need access to, or to manipulate, extended
    type information
    would need to use the user space library.

    One approach, that I haven't studied in detail, would be to have a special
    super block device
    to handle binders. All opened binders would be associated with this special
    super block
    so that the 'device' routines are handled properly.

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

     \ /
      Last update: 2005-03-22 13:52    [W:0.029 / U:17.824 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site