bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#10282: change in behavior of du with multiple arguments (commit efe5


From: Eric Blake
Subject: bug#10282: change in behavior of du with multiple arguments (commit efe53cc)
Date: Mon, 12 Dec 2011 15:58:34 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0

On 12/12/2011 03:33 PM, Eric Blake wrote:
>> However, changing the numbers is one thing and missing lines in the output
>> of du is quite another thing.
> 
> Yes, that's the bug I think we introduced - we are mistakenly eliding
> lines of output, rather than listing those directories with 0 attributed
> additional size.
> 
> More importantly, POSIX says of -s:
> 
> "−s Instead of the default output, report only the total sum for each of
> the specified files."
> 
> But we fail that:
> 
> $ mkdir -p /tmp/a/b
> $ cd /tmp/a
> $ du -s . b
> 8     .
> $ du -s b .
> 4     b
> 4     .
> 
> We correctly deduced that only 8 units were occupied (that is, b was not
> double-counted in either approach), but we _failed_ to list b in the
> first approach.  I think POSIX requires the output to have been:
> 
> $ du -s . b
> 8       .
> 0       b

POSIX also says:

"Files with multiple links shall be counted and written for only one
entry. The directory entry that is selected in the report is unspecified."

But even historically, command line arguments were always listed, even
if they are otherwise multiple links.  On Solaris 10, for example,

$ touch a
$ ln a b
$ /bin/du a b
1       a
1       b

instead of omitting one of the two entries.  The omission only occurs
during recursion of a directory on the command line:

$ /bin/du -a .
1       ./b
4       .

> I think that a saner output would be:
> 
> $ du . b
> 4       ./b
> 8       .
> 0       b

So this would be okay (even though we encountered b via two different
links, the second encounter was a command line, so it should not be
elided entirely, but listing 0 would make it obvious that there is no
further disk usage to count),

> $ du b .
> 4       b
> 0       ./b
> 4       .

whereas this proposed line of '0 ./b' is questionable (we could argue
that ./b should not be elided because no other link to b was printed
during recursion, or we could argue that elision should trump recursion
once the command line arguments have been printed).

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]