side note: The mere existence of the '..' entry is actually a fair bit of a problem in and of itself... it ties the entire filesystem into one freakin' mess, instead of allowing you to treat each subdirectory (and subdirectory there-of) as it's own little independent world [think versioning, copy-on-write, etc, etc, etc...]. I'm pretty sure that the '..' entry should be simulated somehow...
On Mon, Dec 15, 2008 at 11:31, Maciej Żenczykowski <[email protected]> wrote: > I believe '/usr/bin/find' does use the link count for some > optimization (it assumes a directory has nlink-2 subdirectories, -2 > since 1 for the link from parent to itself, and 1 for the '.'), but > should fall back to a less optimized mode if it sees a mismatch... > > I've definitely seen it complain about mismatched link counts many > times before... > > On Mon, Dec 15, 2008 at 10:35, Daniel Phillips <[email protected]> wrote: >> On Monday 15 December 2008 03:26, Maciej Żenczykowski wrote: >>> > answer if some unlinks have been deferred. For some strange reason, >>> > directory link count only includes subdirectories, not regular files or >>> > other kinds of entries, so that cannot be relied on. I am not sure >>> >>> That's because it's counting the '..' links in the subdirectories. >> >> Duh, thanks And does anything actually rely on this count being equal >> to the number of subdirectories as opposed to being > greater than two >> for a non-empty directory? >> >> It would be a lot more useful to Tux3 as a directory in-use counter >> than as a subdirectory counter. >> >> Regards, >> >> Daniel >> > _______________________________________________ Tux3 mailing list [email protected] http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3
