> This illustrates something that's bugged me about Un*x-oid systems
> for a long time: the lack of any way to get a handle on a file (as
> distinct from what open() returns, which is more like a handle on the
> file's contents).  [...handle, hunlink, hchown, unhand, etc...]

This sounds as though it would require a great redesign of the
filesystem semantics.  Think about what we've presently got.

Consider unlink().  This is not an operation on a file; it is an
operation on file _names_.  unlink() removes a directory entry.  The
only affect it has on the file itself is adminstrative; the link count
is just a way of permitting easy garbage-collection of inaccessible
files.  (Reference-counting garbage collectors work fine for data
structures that can't be circular.  And indeed, it takes root to
introduce a circularity into the filesystem, and if that's done, the
reference-counting garbage collector breaks down.)

Thus, if you want hunlink() to work, a handle must really be a
<directory,name> pair.  But if you do that, you are still leaving
yourself open to racing against changing what that name in that
directory refers to.  The races will be not as bad as using the full
path, but the situation will be no better than what you can already get
by doing a chdir() and then using a slash-free (relative) path.

Actually, a file descriptor returned by open() _is_ a handle on the
file itself; that's how come fchmod() and fchown() exist - they are
operations on the file, not its contents.  (fchdir() and ftruncate()
are related, but they are less clearly operations on the file itself as
opposed to its contents.)

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B