Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site cornell.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!qantel!hplabs!tektronix!uw-beaver!cornell!jqj
From: jqj@cornell.UUCP (J Q Johnson)
Newsgroups: net.unix-wizards
Subject: Re: unix file system
Message-ID: <3631@cornell.UUCP>
Date: Sat, 3-Aug-85 22:35:21 EDT
Article-I.D.: cornell.3631
Posted: Sat Aug  3 22:35:21 1985
Date-Received: Tue, 6-Aug-85 08:37:55 EDT
References: <3287@dec-mrfort.UUCP> <5100003@rocksvax.UUCP>
Reply-To: jqj@cornell.UUCP (J Q Johnson)
Organization: Cornell Univ. CS Dept.
Lines: 45
Summary: 

File attributes clearly don't fit well into the Unix philosophy (what are
the attributes of a pipe?), so this discussion should probably shift to
some other news group.  However, a couple of points:

Unix does have a very few file attributes, e.g. file owner, group,
modes, last access, number of links, etc.  A purist would argue that
none of this data should be maintained for a file.

If you're going to have attributes, it is desirable to make them user-
extensible, e.g. using the environment-var format suggested in a
previous posting (however, that suggestion makes binary data in
attributes a real pain!).  It is also desirable to allocate lots of
space to attributes.  The Xerox Star file servers have a file structure
which allows some ridiculous amount of attribute data (64K?).  As you
might guess, attributes in that OS are used to hold all sorts of
things, including file names!

Typical useful attributes:  (1) file type (text file, binary file,
directory, etc.), (2) file owner, (3) last read/write/create date, (4)
last writer, (5) EOF pointer (many OSes allow data on the last page
after the EOF pointer), (6) protection data, (7) version #, (8) backup
information such as the magtape id on which the file was last archived,
(9) documentation on the file (e.g. a change log), etc.

If I were implementing a file system with attributes, I'd store
attributes in a parallel data space to the "standard" file data space,
implemented by a parallel set of page tables to the standard ones but
associated with the same inode or directory entry (depending on where
the file system kept its page tables) -- thus, the amount of attribute
data would be expandable just as the size of the file was, and I'd be
able to share a lot of code.  But since I'd access attribute data with
a different set of system calls (aread, awrite, aseek would be adequate,
but a higher level set would be preferable) they wouldn't get in the
way of programs that wanted to treat the file as "just data".

Of course, if you're serious about generalized attributes, why limit
the attribute access function to simple names?  And why limit the
attribute values to simple strings (or static binary data)?  Some DBMS
systems record a change log containing every transaction affecting the
file; in such a system a reasonable extension of "attributes" would
be a time-valued attribute that returned statistics on the state of the
file at that time.

All in all, though, I guess generalized attributes aren't all that good
an idea.