[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    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean