bug#17546: Problem with du

[Dale R. Worley]

This message is a sequel to the message copied below.

There is a somewhat subtle problem with how du "never counts the same
file twice".  This behavior is what one would expect by default when
du is processing the directory tree which is a single argument, but
it's *not* the behavior that I expect when processing two arguments.
In particular, if one file is part of two argument directory trees, du
will count its space as space within the first argument, but not
within any later argument that contains it.

This leads to startlingly odd behaviors, such as the order of the
arguments to du will change the resulting output, and the output of du
when applied to two arguments is not the concatenation of the outputs
of two executions of du, one with each argument.

It seems to me that the correct behavior (giving what people expect)
is to clear the "hard link cache" between processing each argument, so
that if argument trees overlap, the overlapped part is counted
properly in each argument.  Given that before release 8.6, the order
of arguments didn't matter, it seems to me to be unlikely that many
users are specifically depending on caching between arguments.

(Please include my address in any responses.)

Thanks,

Dale


http://lists.gnu.org/archive/html/bug-coreutils/2010-11/msg00176.html
> From:         Paul Eggert
> Subject:      bug#7439: du failing at "du -sh . *"
> Date:         Fri, 19 Nov 2010 08:52:39 -0800
> 
> On 11/18/2010 05:08 PM, Mathias Linnemann-Emden wrote:
> > So not only the output of "du -sh . *" is wrong (not showing du for *),
> > but also the output of "du -sh * ." is incorrect (showing only 4K
> > instead of 8K for ".").
> 
> NEWS lists this as a bug fix in release 8.6:
> 
>   du no longer multiply counts a file that is a directory or whose
>   link count is 1, even if the file is reached multiple times by
>   following symlinks or via multiple arguments.
> 
> The idea is that a single invocation of du never counts the same
> file twice.  This was always true for files with multiple hard
> links (you probably didn't notice that), and now it's consistent
> for all files.
> 
> To get something like the old behavior, you can use "du -l",
> or invoke "du" separately for each file (depending on how you
> want hard links treated).