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).
