[ On Saturday, July 12, 2003 at 04:57:27 (-0400), der Mouse wrote: ]
> Subject: Re: funlink() for fun!
>
> >> 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.

s/could/should/

> Sure it could.

But it should, not, indeed must not, else a fundamental feature of how
unix I/O works would be trashed all to hell.

> 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.

Yes, exactly.

>  This is a clue that what you are trying to do is
> inappropriate.

No, not really -- it should be obvious to anyone aware of how unix
filesystems are structured that implementing funlink() has it
limitations and its costs.

>  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.

A file is more than its contents -- it is all the metadata that controls
access to the content and allows the content to sit on the same storage
media along with many other distinct files.

Unlink() cannot, and luckily does not, "just" destroy links to files.
The primary purpose of unlink() is _also_ to decrement the link count in
the file metadata.  Unlink() _always_ acts on both a file and the
directory entry which points to that file.  However directory entries
(names) are just pointers to the real files.  The only part of what
unlink() also often does in addition to those first two critical
functions, which could safely be left for some cleanup daemon to do,
would be the moving of data block pointers from inodes which have a link
count of zero to the free list.

> You insist on trying to somehow tie an open file descriptor to a
> particular link to its file

Indeed since that is the only way to implement the semantics of
funlink() as I've described it.  It's not such a difficult thing to do
for the most common case, even if one doesn't cache the opened filename,
though it could potentially incur a lot of disk reads....

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>