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.
Also, I dispute your claim that tools have to change. For instance, ls will misbehave: it will think your file is a directory. 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. It reminds me of symlinks, which I detest. I understand why they were created - cross-device links didn't work - but they broke just about everything by introducing a second kind of file. Half the time you want the file, half the time you want the file it describes. They're pointers, and deciding whether the operation wants the pointer's value or referent means a new system call shows up, a new flag appears everywhere, and one usually guesses wrong the first 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. If you want attributes, rethink the system, don't hack it. -rob On 8/20/07, Douglas A. Gwyn <[EMAIL PROTECTED]> wrote: > I was thinking more about the subject, and extended attributes. > Here is an alternative proposal to implement extended attributes: > > (1) Everything stays the same as it is (Plan 9 or old-Unix) > except: > (2) An attempt to read(2) or write(2) a directory will succeed > if and only if there is a .data entry, in which case it will > access contents of the .data object. > > None of the existing tools need to be changed. > > To add attributes (all done in user space): > (a) Move the current file (terminal node) to a temp name. > (b) Make a directory in its place, with the original name. > (c) Move the temp name to original_name/.data . > (d) Create a file (subdirectory?) .attributes . > (e) Populate the .attributes . >
