GNU bug report logs - #10282
du: hard-links counting with multiple arguments (commit

Previous Next

Full log

Message #11 received at 10282 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
Cc: Kamil Dudka <kdudka <at> redhat.com>, Paul Eggert <eggert <at> cs.ucla.edu>,
	10282 <at> debbugs.gnu.org
Subject: Re: bug#10282: change in behavior of du with multiple arguments
	(commit efe53cc)
Date: Mon, 12 Dec 2011 15:58:34 -0700

[Message part 1 (text/plain, inline)]

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   eblake <at> redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.