Thus spake Greg A. Woods ("GAW> ") sometime Today...
GAW> > Um, slightly off-topic, but wouldn't funlink() be somewhat disastrous in
GAW> > practice?
GAW>
GAW> No more than unlink(), provided that the link count was only one;
Well, yes, there is always that restriction, but that wasn't stated.
GAW> alternately the pathname could be cached in the kernel. ;-)
I don't get that at all, sorry. What good would that do for a file that
had (N>1) links to it? If the (st_nlink == 1) restriction is not
enforced, funlink() would be tantamount to clri...
Gah! You know what? [I'm so chagrined -- this took me several passes.]
funlink() would STILL be tantamount to clri, and it would require the same
procedure (fsck) from which to recover, unless the kernel DID cache the
paths of every open (I know it caches vnodes, but pathames?) until (last)
close or until unlink.
GAW> > That would require a file-
GAW> > system cleaner process or a routine that knew instantly how to match inode
GAW> > numbers to pathnames
GAW>
GAW> Why "instantly"? funlink() could block until it found the directory
GAW> entry and confirmed that the link count was still one. :-)
<quiz>
[ ] You expect me to wait that long for funlink() to return from that
procedure?
[ ] ...on a 1GB filesystem?
[ ] ...with a high density of inodes?
[ ] ...on a system with a slow CPU?
</quiz>
I'm guessing the smileys all over the place are conveying your intent that
funlink() would not work at all, practically speaking...
GAW> > You will note that there is no converse
GAW> > routine, since while name -> ino-dev is unique for each ino-dev, the
GAW> > reverse is untrue -- consider /foo/bar/.. and /foo, for example...").
GAW>
GAW> Yes, that's strictly true, but your example is slightly wrong. :-)
I see that's either because they're directories or, more likely what you're
hinting at, because /foo/bar may be on a different dev than /foo.
I should say, then, "consider /foo/bar/.. and /foo on the same partition,
for example...".
--*greywolf;
--
NetBSD: Professional power!
