Subject: Re: funlink() for fun!
To: NetBSD Kernel Technical Discussion List <tech-kern@NetBSD.org>
From: Greywolf <firstname.lastname@example.org>
Date: 07/12/2003 02:11:14
Thus spake Greg A. Woods ("GAW> ") sometime Today...
GAW> > could see would be to set the reference counter in the inode to zero,
GAW> No, not zero -- just decremented by one (assuming the proper directory
GAW> entry can be found).
Greg, file descriptors are not associated with pathnames. There is no
"proper directory entry".
unlink() operates on a pathname (i.e. dirent). Only. That's it.
GAW> No, absolutely NOT! unlink() doesn't to this for VERY good reasons, and
GAW> funlink() could not do so either.
unlink() operates on a pathname from which an fd might otherwise
be generated. funlink would work on an fd, from which it is not possible
to divine a unique name. Matthias is saying effectively that funlink()
is tantamount to clri(), plus revoke() semantics on all open fds to the
node that just got funlink()ed (something I'm not altogether sure I agree
with, since you might actually want the reference, but not the physical
object, to remain present.).
In short, he gets the concept.
GAW> > It would indeed delete the file, not a
GAW> > directory entry, which is literally what the caller requested.
GAW> That's completely wrong given how I've described funlink().
You want a 1:1 relationship between filehandles and pathnames, more or
less. Who's been taking lessons from M$, now?
NetBSD: We Suck Less