Messages in this thread | | | From | root <> | Date | Mon, 21 Jun 1999 17:10:02 +0000 (/etc/localtime) | Subject | (reiserfs) Re: I discussed reading directories as files with jra, Stallman, and loic |
| |
Your proposal seemingly doesn't address the ordering issue, and it doesn't solve the W2k problem, that is, it doesn't allow someone to create a file, then add another stream (that is, make the become also a directory, and create a non-default file in it as well as the current default file). It is not that I am focused on the needs of Samba here, it is that I think their needs are an interesting measure of the model.
I don't see where binders are more general.
That said, if you want to work on helping to implement this, great, I think we can start with doing the easy tasks, and then do the hard ones later.
Hans
Wanderer writes: > 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/
| |