Bug 747075

Summary: du reporting inconsistent with multiple arguments
Product: [Fedora] Fedora Reporter: Elliott Forney <elliott.forney>
Component: coreutilsAssignee: Kamil Dudka <kdudka>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: rawhideCC: kdudka, maxamillion, ovasik, ttomasz, twaugh
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-02-15 06:56:15 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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

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

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

http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/23474
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:

http://austingroupbugs.net/view.php?id=527#c1104
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.