Red Hat Bugzilla – Bug 561869
"du -s *" reports confusing directory sizes
Last modified: 2012-07-16 07:42:30 EDT
Created attachment 388813 [details] Script to reproduce the output in the report Description of problem: "/usr/bin/du -s *" reports different sizes of the sub directories depending on their position in the "*"-list. Version-Release number of selected component (if applicable): du (GNU coreutils) 7.6 How reproducible: Always. Steps to Reproduce: 1. Run attached script (clones git.git from kernel.org in a new directory called Bug/) 2. 3. Actual results: ================== 43560 git 132 git.git ================== 27620 git.git 16072 hit ================== 43696 . Expected results: Not sure what to expect. Probably ================== 43560 git 27620 git.git ================== 27620 git.git 43560 hit ================== 43696 . Of course the exact sizes will change as the remote repository is updated. Additional info:
Thanks for reporting it and preparing the reproducer! The bug is triggered by hard links - it vanishes after: $ find Bug -type f -links 2 -delete I haven't yet looked into sources, but it seems like FTS hashing is not cleared properly before the jump to next operand.
Additionally there is a clash with -c: $ mkdir a b $ dd if=/dev/zero of=a/file count=10 $ ln a/file b $ du 12 ./b 4 ./a 20 . $ du a 12 a $ du b 12 b $ du a b 12 a 4 b $ du b a 12 b 4 a $ du -c a b 12 a 4 b 16 total I've added the upstream maintainer. Jim, could you please have a look at the example?
Now looking into info documentation, it seems to be documented such: If two or more hard links point to the same file, only one of the hard links is counted. The FILE argument order affects which links are counted, and changing the argument order may change the numbers that `du' outputs.
I am closing the bug as NOTABUG. The behavior is a bit counter-intuitive, nevertheless properly documented.
*** Bug 739574 has been marked as a duplicate of this bug. ***