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

    > In article <m10vnlI-003VuJC@reiser>, root <reiser@ceic.com> 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 majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

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