> I guess the choice [...] depends on what possible reason one might
> have for implementing funlink() in the first place, and thus how one
> defines it.

> If all one is trying to do is flesh out the set of f*() system calls
> which have file descriptor parameters to make it orthogonal to the
> set which have pathname parameters then

...you shouldn't do funlink() in this form in the first place, as
unlink() is not an operation on a file but an operation on a link to a
file.

Now, an funlink() that takes an fd on a directory and a (slashless)
component name, that would be a sensible way to add an fd-based variant
of unlink().

But there are more serious things to fix first, like the inability to
use open()/fchdir() with directories that are execute-only.  (To fix
this right, we need something like O_NOACCESS.)

> (I suspect always caching the file's parent directory vnode for all
> open files as well would also add too many more complications, and it
> still wouldn't help if the rename changed the file's parent
> directory.)

It could, because then rename() could notice the change and change the
cache to refer to the new location.  (In which case I'm not sure how
fair it is to still call it a "cache"....)  I'm not sure what to do
with link/unlink pairs, though.  Neither call should update the cache,
but together they should....

/~\ 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