> Seriously, I have always thought that there should be an funlink()
> command which would take a file descriptor and unlink the inode
> associated therewith.  It would really mess up the structure, though,
> and in the case of files with more than one link it would _require_
> that fsck be run.

Actually, that's not even "possible."

a file descriptor references a vnode, which references an inode.
inodes and vnodes and file descriptors don't (and quite rightly don't)
have any notion of the inode's "parent" directory or directories,
i.e. the things from which it would be unlinked.

If you were to try something like this, you'd effectively have to put
fsck _in_ the kernel, or at least part of it, because you'd have to
scan the whole directory hieararchy to find out where the inode was
actually attached.  (You also have to deal with the case in which the
parent directory no longer exists...  I'm pretty sure that's currently
possible.) 


unlink, rename, etc. are namespace operations, and namespace
operations only.  Therefore, they _need_ names.

The only viable solution to 'atomic remove/rename/etc.' operations
that I can think of is one like the one matt already proposed: be able
to pass a cookie that'll only match the file if it's actually the same
file.


It's worth noting that link() could, in fact, have a variant that
takes a file descriptor for the 'source' file, and even a file
descriptor for the destination directory.  (It'd still need a string
for the linked-to file name, though.  if that string were a complete
relative path, the 'destination directory' descriptor could be a
descriptor for the root of a 'destination tree'.)  However, I don't
think implementing that is either necessary or appropriate.


cgd