This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 561869

Summary: "du -s *" reports confusing directory sizes
Product: [Fedora] Fedora Reporter: Peter Eriksen <s022018>
Component: coreutilsAssignee: Kamil Dudka <kdudka>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 12CC: kdudka, meyering, ovasik, techtonik, twaugh
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-02-04 11:12:59 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
Script to reproduce the output in the report none

Description Peter Eriksen 2010-02-04 10:21:30 EST
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:
Comment 1 Kamil Dudka 2010-02-04 10:31:27 EST
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.
Comment 2 Kamil Dudka 2010-02-04 10:56:39 EST
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?
Comment 3 Kamil Dudka 2010-02-04 11:01:03 EST
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.
Comment 4 Kamil Dudka 2010-02-04 11:12:59 EST
I am closing the bug as NOTABUG.  The behavior is a bit counter-intuitive, nevertheless properly documented.
Comment 5 Ondrej Vasik 2012-07-16 07:42:30 EDT
*** Bug 739574 has been marked as a duplicate of this bug. ***