[ On Thursday, July 10, 2003 at 17:31:11 (-0700), Greywolf wrote: ]
> Subject: Re: funlink() for fun!
>
> In order for funlink() to work, you will need both caching of open
> filenames and the requirement that st_nlink == 1.

No, not really -- i.e. not just to make it "work".  You only need one or
the other....

> You'll need the caching
> to make sure you can find the name quickly, and

"quickly" is irrelevant -- the call would always have to block until it
found the right directory entry, regardless.

Assuming one doesn't want to pay the price of caching all open filenames
then whether funlink() locks the inode first before searching for the
directory entry, or last, is the only optimisation one need consider.  :-)

> the one-link requirement
> to insure you don't break things.

First off if you have cached the open file name then you don't need to
worry about the link count -- funlink() would always remove the intended
file in that case since it knows the file's name precisely.

The restriction on a link count of one would only be necessary when open
filename caching wasn't implemented.  It would be needed to make sure
the kernel didn't find the "wrong" filename first and unlink it instead
of the filename that was opened to create the file descriptor passed to
funlink().

> I had the experience of tripping over something like the following in an
> ls -l once.  (ONCE.)
> 
> -rw-r--r--  0 root  wheel  2619 Jun  9 09:47 /some/path/I/forget

Did it persist that way for any period of time?  Or was it a momentary
quirk that could have been caused by a race condition for a file that
was in the process of being unlinked?

> I think had I tried to access it or remove the entry, I would have had
> some problems.  My only option, to my mind, was to shut down the machine,
> umount everything (hoping nothing panicked), and reboot it single-user and
> force fsck to fix everything it could.

If that file really did persist until you fsck'ed then it sounds like a
corrupt filesystem was mounted without being properly fsck'ed the first
time around -- perhaps because of a bug in fsck; or perhaps there was a
bug in the filesystem code, or an undetected data corruption on the
disk, that caused the error to appear since the last boot.

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