Re: [9fans] everything is a directory

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

"Rob Pike" <robpike@gmail.com> wrote in message 
news:7359f0490708200802g2ba8abc0jd61b4f9550bc382f@mail.gmail.com...
> This is only possible because someone said it was OK to
> break directories in the first place.  Not too long ago, if you
> wanted to read a directory you could use a read system call.
> I see no functional reason that that symmetry was worth
> breaking.

That was already changed long before "extended attributes"
entered the picture.  On modern Unix systems (since NFS
or slightly before) and even on Plan 9 one doesn't normally
read and parse actual directory content; the OS/library has
a different interface for directory interrogation.

> Also, I dispute your claim that tools [don't] have to change.
> For instance, ls will misbehave: it will think your file
> is a directory.

But under my proposal that is correct.  An attributed file
*is* an ordinary directory (with ordinary files and/or other
directories as members).  But if you "cat" or "grep" the file
name, you access its .data member.  Since these days the
actual directory content isn't meaningfully accessed, that frees
it up for some other interpretation, such as what I proposed.
(You can also access the file data as path/name/.data, so
there is nothing misleading about this use of the existing
filesystem structure.)

(An implementation detail I didn't mention: I recommend
that the .data member always be the first entry for speed
of access, thus no "." or ".." entries [unlike Solaris-10
extended attributes]; those should be handled by the OS
path interpreter, as on Plan 9.)

>  And there will be lots more instances
> because, fundamentally, stat will be misleading.
> Then all the existing tools will be changed because
> people will want to use them on attributed files and
> their attributes.

There is no reason why "attribute aware" tools shouldn't
be developed, if attributes are indeed useful (something
I'm not yet convinced of).  My purpose was to figure
out a way of implementating extended file attributes with
minimal disruption to the usual Unix/Plan 9 file model.
Note that the Linux/Solaris-10 (Posix?) implementation
requires separate system calls and extensive changes to
standard tools *and* to the way those tools are invoked.

> It reminds me of symlinks, which I detest. ...

Yes, the analogy is close.

> but they broke just about everything by introducing a
> second kind of file. ...

Which is what we want to avoid this time.

> Attributes, as created or as posited here, are better
> only because for the most part one can ignore them
> altogether. Except when you can't.

Unfortunately, if you forget about attributes on Linux/
Solaris-10, you far too easily do what users would
definitely consider to be "the wrong thing".  That's
*why* so many standard tools had to be modified
using their approach to extended attributes.

> If you want attributes, rethink the system, don't hack
> it.

So what is a better proposal?