> I don't know, but AFS does have ACLs, and I imagine AFS severs use
> these bits for the same purpose which started this discussion:
> a reference to an inode containing per-file ACL info.

Nope, that's not the way they're used.

> Someone with access to AFS source should really comment.

There are five 32-bit longwords used by AFS.

AFS adds an additional level of indirection.. logically speaking the
ilist is sort of two-dimensional ("volumes" within the partition in
one dimension, inode within volume on the other..).

One of them is used analagously to the file generation number added by
Sun for NFS.

of the other four, it appears that there are:
	- a magic number, 0x84fa1cb6, indicating that this is an inode
	managed by the AFS volume package.
	(this could be handled as a file attribute using the 4.4bsd
	attribute system; fsck needs to not do with directory connectivity
	checks/repairs for inodes with this attribute).
	- the volume number of the volume the inode is a member of.
	- the volume-internal node number within the volume that the
	  inode "lives at"
	- the AFS-protocol-visible data version number (used for cache
	  coherance).

Systems which don't have room for all of these fields on disk put one
or more of these in an auxilliary file (which can, of course, get out
of synch with the inode).

Each volume has an auxillary inode containing additional metadata and
its "ilist".  I suspect that acls may live there as well but haven't
read enough code to be certain at this point.

					- Bill