lkml.org 
[lkml]   [1999]   [Jun]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.726 / U:0.816 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site