bug#10281: change in behavior of du with multiple arguments (commit efe53cc)

[Paul Eggert]

On 02/18/2013 12:18 AM, Elliott Forney wrote:

> I find it unintuitive that the number in a line of output from
> du does not necessarily reflect the size of the corresponding
> directory or file.

That's been true forever.  All versions of 'du' do that.
For example, with Solaris 11 du:

$ ls
$ echo xxx >a/f
$ ln a/f b/f
$ du
16      ./a
8       ./b
32      .
$ du a
16      a
$ du b
16      b

This sort of thing has been the normal behavior since the
1970s and it's unlikely that we'll want to change it now.

> I find it surprising that the order of command-line arguments to
> du may affect the output of du.  Users don't expect this.

Also, users might not expect that the order that directory entries
are explored can affect the numbers that du outputs.  It's the same thing.
But we can't and shouldn't change the the directory-entry behavior;
and this is an argument that we shouldn't change the behavior for
command-line arguments as well.

> Is it just me or does anyone else think this is convoluted?

Yes, it's convoluted, but complexity is inherent to any
file system that has hard links and where 'du' is supposed to
count actual and not apparent disk usage.  There's no way to
escape this complexity entirely: it has to be reported to the
user somehow.  No matter what method 'du' uses, one will be
able to construct confusing examples like the above.  So the
mere existence of examples that cause confusion is not sufficient
evidence that we should change du's behavior.