Subject: Re: funlink() for fun!
To: NetBSD Kernel Technical Discussion List <tech-kern@netbsd.org>
From: Greywolf <greywolf@starwolf.com>
List: tech-kern
Date: 07/10/2003 17:31:11
Thus spake Greg A. Woods ("GAW> ") sometime Today...

GAW> Nothing's been sidestepped here.  Perhaps you've forgotten either one
GAW> of:  (a) the option of caching open filenames; or (b) the qualifier
GAW> that funlink() could/should fail/misbehave if the inode has multiple
GAW> hard links.

In order for funlink() to work, you will need both caching of open
filenames and the requirement that st_nlink == 1. You'll need the caching
to make sure you can find the name quickly, and the one-link requirement
to insure you don't break things.

The only other option would be to keep an inverse lookup db somewhere, and
that could get prohibitive (unless the means you kept was a db which
contained not actual names, but pointers to ino-devs which were
directories, and the offsets within from whence names could be retrieved
(since the kernel can divine things like data blocks from inodes and thus
dereference them...)).

[that could have implications of either robustness or frailty, depending
 on how you looked at it.  At first glance, something like that would
 enable run-time consistency capability, but I think it's probably more
 frail than that (I get starry-eyed at new features, at least until I
 discover their drawbacks, so I'm probably not (always) the best judge of
 robustitude).

 I mean, think about it:  you'd get a cross-check of link counts available
 at any time.  iname() would be possible, although it would return an
 array of objects rather than a single one; but if there was an
 inconsistency between the link count on the ino and the number of objects
 returned, that could be useful.  Don't ask me how (see "starry-eyed",
 above).

 I'm sure someone, somewhere, before me, has thought of doing this. I'm
 equally sure that this person has presented it, only to have it go down
 in flames because of the unnecessary complexity it added to things like
 open, creat, unlink, link, mkdir, rmdir and rename.

 But I digress...]

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

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.

				--*greywolf;
--
NetBSD: we put the Net in BSD.