[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#6557: du sometimes miscounts directories, and files whose link count
bug#6557: du sometimes miscounts directories, and files whose link count equals 1
Sun, 04 Jul 2010 16:03:11 -0700
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:188.8.131.52) Gecko/20100423 Thunderbird/3.0.4
On 07/03/10 01:18, Jim Meyering wrote:
> Note that the vendor versions of "du" from at least Solaris 10,
> openBSD, netBSD and freeBSD print both lines.
> I prefer the new semantics, especially when using --total:
Yes, the new semantics make more sense. If you prefer the
traditional semantics, you can still get them, by using
"du A; du B" rather than "du A B". In contrast, there's no way
to get the new (and better) semantics if all you have is the
traditional behavior. This is another argument for staying
with the new semantics.
GNU du had already diverged from the traditional semantics, in
that it kept track of hard links across argument boundaries, which
traditional du does not. (This behavior is documented in the
Solaris 10 du -L is clearly busted, by the way, in that it counts
files multiply if their link count is 1. I wouldn't be surprised
if the BSD du implementations are busted too. This behavior is not
reasonable (and clearly doesn't conform to POSIX). So in some sense
that weakens the argument of following the precedent of these older
implementations in this area.
> What do you think of breaking with that tradition? POSIX does appear
> to say that for each "FILE" argument du must print a line, but it also
> mentions how with linked files, the space must be counted only once.
> You can definitely consider listing the same file twice as being
> analogous to a file being hard-linked.
The POSIX requirements are contradictory, and clearly the authors
had not thought through the implications. When they're contradictory
we should do the best we can, and perhaps get POSIX fixed at some point
to clearly allow the new GNU behavior (as well as clearly allowing the
traditional behavior of course; right now POSIX does neither).
Thanks for fixing the test cases to match the new behavior.
I had only run the test case that I had updated, and should
have run them all (my only defense being that I'm using a
circa-2003 desktop to test....).