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

[Elliott Forney]

> 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

The example you give is different in one important way:  it involves
multiple hard links.  The example I gave involved only nested
directories.

With Solaris du, each line corresponds to the file/directory size
given that there are not multiple links:

$ mkdir one one/two
$ echo xxx > one/two/f
$ du -s one one/two
12      one
8       one/two
$ du -s one/two one
8       one/two
12      one

Whereas in gnu du we now have:

$ du -s one one/two
12      one
$ du -s one/two one
8       one/two
4       one

I guess part of the reason I see this so much is that I tend to use
the -s option to get the summary sizes of a list of directories and
sometimes they are nested.  I really think this is the most common
usage for users.

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

The behavior that we've had since the 70's was changed in the recent
release of du.  That's the whole reason this bug report popped up.  I
will admit, however, that I sometimes think we should all be more open
to changes but, in this case, I think the change is more confusing.

> 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.

Yes, this is a justification for having the order of arguments matter,
but only if one concedes that multiple command-line arguments should
not be recounted.

> 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.

Of course convoluted examples can always be constructed, but the
example I gave should not be overly complex.  It is a typical use
case.

It really boils down to whether or not multiple command line arguments
should be recounted.  There is no question in my mind about recounting
multiple links (not recounting links is the historical behavior if for
no other reason).