[Tux3] Deferred namespace operations, Defer rename

Maciej Żenczykowski zenczykowski at gmail.com
Mon Dec 15 11:36:10 PST 2008


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
<zenczykowski at gmail.com> 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 <phillips at phunq.net> 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
Tux3 at tux3.org
http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3


More information about the Tux3 mailing list