>> I addition, the only proper semantics for an funlink() system call I
>> could see would be to set the reference counter in the inode to zero,
>> close/invalidate the file and all descriptors to it [...]

> No, not zero -- just decremented by one (assuming the proper
> directory entry can be found).

> No, absolutely NOT!  unlink() doesn't to this for VERY good reasons,
> and funlink() could not do so either.

Sure it could.  If you want it to be an operation on the file, as
opposed to a link to the file, it has to be _something_ that is
independent of any particular pathname to the file.

Otherwise, you're making it an operation on a link that was at some
past time (save pathname at open() time) or is now (search filesystem)
linked to the file, and only secondarily an operation on the file
itself.

You have to go through great contortions (saving pathnames, searching
filesystems, checking that nlink==1 and/or that the pathname still
refers to the same file) to make funlink() perform the same operation
unlink() does.  This is a clue that what you are trying to do is
inappropriate.  I don't know where you got this resistance to
comprehending that unlink destroys links to files, only secondarily
affecting the files themselves, but it's clear to me that you have it.
You insist on trying to somehow tie an open file descriptor to a
particular link to its file, and, since file descriptors refer to
files, not links to files, you're having trouble.  Changing file
descriptors to refer to not files but particular links to files would
be a major philosophical change, and, as you're discovering, would
demand either a thorough redesign or some extremely heavy performance
penalties.  It probably could be done, but I see no point, and I do not
understand why you persist in trying to do it.  In any case, I see no
point in discussing it further with you.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B