Bug 747075

Summary:	du reporting inconsistent with multiple arguments
Product:	[Fedora] Fedora	Reporter:	Elliott Forney <elliott.forney>
Component:	coreutils	Assignee:	Kamil Dudka <kdudka>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	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 11:56:15 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Elliott Forney 2011-10-18 17:55:49 UTC

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 18:14:59 UTC

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 22:59:29 UTC

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 22:10:00 UTC

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 22:11:01 UTC

Definitely not caused by hard links.

Comment 5 Kamil Dudka 2011-12-12 12:15:41 UTC

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 14:12:44 UTC

raised upstream:

http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/23474

Comment 7 Kamil Dudka 2011-12-13 16:52:12 UTC

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 08:50:41 UTC

*** Bug 797383 has been marked as a duplicate of this bug. ***

Comment 9 Elliott Forney 2012-04-24 23:32:51 UTC

Raised to austin group for interpretation on POSIX standard:

http://austingroupbugs.net/view.php?id=527#c1104

Comment 10 Ondrej Vasik 2012-04-25 05:48:30 UTC

Thanks for information.

Comment 11 Kamil Dudka 2013-02-15 11:56:15 UTC

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.