Description of problem: du -s reports different results when used on individual directories versus a number of directories passed as command line arguments if one of the directory contains another, as shown below. Version-Release number of selected component (if applicable): coreutils-8.10-2.fc15.x86_64 How reproducible: Always. Steps to Reproduce: 1. du -hs subdir 2. du -hs . 3. du -hs subdir . Actual results: $ du -hs slides 44M slides $ du -hs . 62M . $ du -hs slides . 44M slides 18M . Expected results: Here is the output from Fedora 14 with coreutils-8.5-7.fc14.x86_64 $ du -hs slides 44M slides $ du -hs . 62M . $ du -hs slides . 44M slides 62M . Additional info: It looks like the new version of du will subtract subdir from . if both are given as arguments. I suppose this makes sense in a way but it seems counter-intuitive to me and it deviates from the way that du has always worked in the past (and on other operating systems). This broke one of my scripts and I am concerned that it may break things for other people.
Are there any hard-linked files in that directory? $ find -type f -links +1 If yes, please close this as duplicate of bug 561869 .
No hard links. Except that . is a hard link to the actual directory, right? This looks like a different issue to me. It has also changed between Fedora 14 and Fedora 15.
Here is another illustration where this behavior is confusing: $ ls -l | head -10 total 112 drwx------ 3 idfah grad 4096 Nov 14 15:24 android drwx------ 2 idfah grad 4096 Aug 26 2008 assembly drwx------ 2 idfah grad 4096 May 17 2011 autoconf drwx------ 2 idfah grad 4096 Apr 20 2010 awk drwx------ 3 idfah grad 4096 Sep 14 14:25 bash drwx------ 24 idfah grad 4096 Nov 14 21:04 c drwx------ 2 idfah grad 4096 Aug 21 01:10 c++ drwx------ 2 idfah grad 4096 Jun 27 17:11 cgi drwx------ 5 idfah grad 4096 Oct 22 2009 cuda $ du -ks . * 14868 . Note that du didn't report any of the subdirectories because . came first.
Definitely not caused by hard links.
Sorry for late reply. This seems quite broken. I blame the following upstream commit, which git-bisect points to: http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=efe53cc Unfortunately, the commit is not easily revertible at this point. I will look have a look at the code and try to come with a solution...
raised upstream: http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/23474
There seems to be no clear solution at the moment. Does the option --count-links (-l) solve the problem you originally reported?
*** Bug 797383 has been marked as a duplicate of this bug. ***
Raised to austin group for interpretation on POSIX standard: http://austingroupbugs.net/view.php?id=527#c1104
Thanks for information.
The current default behavior of du is going to be supported by POSIX. The above mentioned --count-links option can be used when necessary. I am closing this bug.