Messages in this thread | | | Date | Mon, 21 Jun 1999 06:45:37 -0700 | From | Wanderer <> | Subject | Re: 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/
| |