Thus spake Greg A. Woods ("GAW> ") sometime Saturday...

GAW> >  I don't know where you got this resistance to
GAW> > comprehending that unlink destroys links to files, only secondarily
GAW> > affecting the files themselves, but it's clear to me that you have it.
GAW>
GAW> A file is more than its contents -- it is all the metadata that controls
GAW> access to the content and allows the content to sit on the same storage
GAW> media along with many other distinct files.

Gee, didn't you just say that "a file is more than its metadata -- it is
all the content" not too long ago?

GAW> Unlink() cannot, and luckily does not, "just" destroy links to files.

Actually, that is all it does.

The fact that the data goes away and gets GCd when the link count and the
reference count (in-core) go to zero is a side effect of the link count and
the reference count (in-core) going to zero.

GAW> The primary purpose of unlink() is _also_ to decrement the link count in
GAW> the file metadata.  Unlink() _always_ acts on both a file and the
GAW> directory entry which points to that file.

You're really trying to force the data and the metadata to be equal.
They are not -- the metadata supercedes the data; the data
is a child of the metadata.   If the metadata goes away, there is nothing
to hold onto the data.  This is UNIX by design.  The only thing that
binds a pathname to a set of data is the fortuitous bunch of hoops that
we must jump thorough to resolve to an inode, i.e. metadata.

GAW>  However directory entries
GAW> (names) are just pointers to the real files.

Correction:  They are pointers to metadata (inodes).  What those inodes
reference is determined once they are accessed; what the references are
specifically are determined once they are open()ed.

GAW> The only part of what
GAW> unlink() also often does in addition to those first two critical
GAW> functions, which could safely be left for some cleanup daemon to do,
GAW> would be the moving of data block pointers from inodes which have a link
GAW> count of zero to the free list.
GAW>
GAW> > You insist on trying to somehow tie an open file descriptor to a
GAW> > particular link to its file
GAW>
GAW> Indeed since that is the only way to implement the semantics of
GAW> funlink() as I've described it.

But "That's not how UNIX (and its derivates) work."

You are proposing a major rewrite to in-core filesystem semantics.

GAW> It's not such a difficult thing to do
GAW> for the most common case, even if one doesn't cache the opened filename,
GAW> though it could potentially incur a lot of disk reads....

				--*greywolf;
--
Microshaft:  Where do you want to crash today?