Greg A. Woods writes:

>But that's the whole point of funlink() (and perhaps even some of the
>other f*() calls, such as fchdir()) -- turn an operation on a file into
>an operation on a filename (i.e. a link to a file).  funlink() would of

I think it's not proper to regard [f]unlink() as operating on a file.
Unlink only operates on directories (which can be simplified as
ordinary files, although this is not quite right).
In most systems you delete files (that's also what probably anybody,
including those who are familiar with the internal workings of a
typical Unix system, is thinking when he's working with the system.)
However, that's not what's being done on Unix.  The kernel deletes
files, opaquely and behind the scenes (if necessary with the help of
fsck after an unexpected reboot.)  Not the user, who just removes
reference entries from directory files.  Of course you know all that,
I just want to emphasize it to support my argument.
That the "garbage collection" of files which are no longer referenced
is more or less immediate by using a simple reference counter in the
file's on-disk structure imho should be regarded as an implementation
detail.  For proper operation, one could also conceive to have a
process which regularly scans the filesystem and collects files which
are no longer referenced (like the memory management of certain
programming languages does.)  It is irrelevant to the exported API how
exactly this is implemented.  Unlink() should only work as an editing
operation on directories.  Any contrived operation that tries to find
a proper name for an open file through its descriptor is a rather
unclean thing which probably cannot be done correctly for all cases
and is way beside the design of the Unix filesystem.

-- 
  Matthias Buelow;  mkb@{mukappabeta.de,informatik.uni-wuerzburg.de}