"Rob Pike" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > 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?
