Subject: Re: funlink() for fun!
To: NetBSD Kernel Technical Discussion List <email@example.com>
From: Greywolf <firstname.lastname@example.org>
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
[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
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",
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.
NetBSD: we put the Net in BSD.