Bug 747075 - du reporting inconsistent with multiple arguments
du reporting inconsistent with multiple arguments
Product: Fedora
Classification: Fedora
Component: coreutils (Show other bugs)
All Linux
unspecified Severity high
: ---
: ---
Assigned To: Kamil Dudka
Fedora Extras Quality Assurance
: 797383 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2011-10-18 13:55 EDT by Elliott Forney
Modified: 2013-02-15 06:56 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-02-15 06:56:15 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Elliott Forney 2011-10-18 13:55:49 EDT
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):


How reproducible:


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.
Comment 1 Kamil Dudka 2011-10-18 14:14:59 EDT
Are there any hard-linked files in that directory?

$ find -type f -links +1

If yes, please close this as duplicate of bug 561869 .
Comment 2 Elliott Forney 2011-10-18 18:59:29 EDT
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.
Comment 3 Elliott Forney 2011-11-18 17:10:00 EST
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.
Comment 4 Elliott Forney 2011-11-18 17:11:01 EST
Definitely not caused by hard links.
Comment 5 Kamil Dudka 2011-12-12 07:15:41 EST
Sorry for late reply.  This seems quite broken.  I blame the following upstream commit, which git-bisect points to:


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...
Comment 6 Kamil Dudka 2011-12-13 09:12:44 EST
raised upstream:

Comment 7 Kamil Dudka 2011-12-13 11:52:12 EST
There seems to be no clear solution at the moment.  Does the option --count-links (-l) solve the problem you originally reported?
Comment 8 Kamil Dudka 2012-02-27 03:50:41 EST
*** Bug 797383 has been marked as a duplicate of this bug. ***
Comment 9 Elliott Forney 2012-04-24 19:32:51 EDT
Raised to austin group for interpretation on POSIX standard:

Comment 10 Ondrej Vasik 2012-04-25 01:48:30 EDT
Thanks for information.
Comment 11 Kamil Dudka 2013-02-15 06:56:15 EST
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.

Note You need to log in before you can comment on or make changes to this bug.