more on file \"attributes\"

[Alexis Dimitriadis]

> There's a lot of stuff in the inode that looks an awful lot like a file
> information block. [It would be cute if there were more room in the
> directory entry -- then we could have separate attribute lists for
> each link to a file...]

  As someone pointed out, a small amount of file "attributes" is
currently being kept on the directory entry itself -- as a suffix to
the filename.  Other programs use specially named files, or system
calls for lock management, etc.  Biff uses the
owner-execute-premission bit of the terminal name as a flag. (ugh).

  I am a big fan of UNIX, but I have often felt that _some_ place to
keep user-defined, out-of-band information about a file should be
provided, say, a field in the inode explicitly set aside for
user-defined information.  Something could be worked out about who
should be able to modify it, and programs that care to could set their
output to have the "attributes" of their input (fstat could be made to
return the relevant info on pipes).

  The "attributes" could or could not be copied when copying a file.
cp has to explicitly set the permission mode of the new file, after all.
More serious would be namespace problems, when more than one family
of applications tries to use the field.

  Please do not flame, I have been carefully following the discussion
on the "file information block", and I have never supported it anyway.  :-)
If I am missing something too, I would like to know.
-- 
_______________________________________________
  As soon as I get a full time job, the opinions expressed above
will attach themselves to my employer, who will never be rid of
them again.

             alexis @ reed

	         ...teneron! \
...seismo!ihnp4! - tektronix! - reed.UUCP
     ...decvax! /