Re: [9fans] Re: everything is a directory

["Douglas A. Gwyn" <DAGwyn@null.net>]

On 8/30/07, jsnx <jason.dusek@gmail.com> wrote:

> On Aug 29, 2:06 am, "Douglas A. Gwyn" <DAG...@null.net> wrote:
> > "jsnx" <jason.du...@gmail.com> wrote in message 
> > > On Aug 23, 1:50 am, "Douglas A. Gwyn" <DAG...@null.net> wrote:
> > >> If .owners was enforced by the OS...
> > > ...that could lead to a lot of 'reserved words'... 
> >
> > Probably it should be .attributes/owner, no new added word beyond
> > what would be needed for extended attributes anyway.

> That's a good idea, and I think that brings us full circle. If we allow for a
> .attributes/content which is accepted by all the major tools, then what I want
> to do is done.

> I'm a bit confused at this point... What is this proposal and why is it attractive? 

> On the surface it looks like you could get everything you want using a pair of files to me.  One to tell you the start of
> the file's normal data (or the end), and the other to let you have scratch space for arbitrary key/value pairs.

> ...

The proposal, as modified, provides a mechanism that can be used to
add extended attributes to files, to encode existing attributes for
files, and to associate all kinds of other files with given files.

The attribute names (analogous to Linux/Solaris extended attributes)
would all be filenames within the .attributes directory attached to
the target file, and their values would be the contents of those
named files.

My proposed implementation, for any Unix-like system including
Plan9, is to change read() on a directory to instead read from the
directoryname/.data file, if it exists, or report an error if it
doesn't exist.  This change should cause no disruption to existing
file structures or applications, since as it stands there is no
purpose in read()ing the contents of a directory (these days we use
walk(), getdents(), etc. instead).  Almost all utilities, including
"tar", would continue to do "the right thing".  Probably "cp" would
need to be changed so it copies directory trees as well as ordinary
files.  Note that there would still be "leaf" (non-directory) files
under my proposal, particularly .data files and not-yet-converted
existing ordinary files.  If one wanted to totally convert the
storage filesystem, then .data entries could be hidden and then all
visible files would indeed be directories.

The primary purpose is to provide support for extended attributes
in a way that works within the traditional Unix hierarchical file
model, without requiring extensive kludges like the Linux/Solaris
implementations have.  A two-file model would also require a large
amount of ad-hoc kludgery to work well enough.