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

[Elliott Forney]

> Unfortunately if memory serves that's not the case either.
> In non-GNU implementations, multiple links are sometimes counted
> and sometimes not.  If you run 'du a b' and a/f and b/f
> are hard links, they might be counted twice, and might not be -- it
> depends on the implementation.

I wasn't aware of that, sounds like there have been inconsistencies
for a long time.

> The area is indeed a mess and no matter what GNU du does it will
> disagree with somebody.

Sure.  As you stated before, filesystems are inherently complex,
especially when links are allowed.  I agree with that.  I apologize if
I am being difficult.  I just want to be sure this discussion is had
because it seems like this is a significant change in behavior.  It
does make sense, it just doesn't feel intuitive to me.

> It might be reasonable to add an option to GNU du to have it mimic
> the behavior you prefer, if we can nail down exactly what that is.

Well, what really bothers me is the second command below.

$ du -ks tmp tmp/bash
1033864 tmp

$ du -ks tmp/bash tmp
182684  tmp/bash
851180  tmp

The size of tmp is underrepresented even though there are no links.
To be honest, however, I can't think of a good way around this.  It
would be nice to simply omit tmp/bash since it is in a directory under
another argument but I'm unsure how that would be achieved without
making things even more convoluted and less efficient.  I am at a
loss.

Once a user is aware of what is going on, the problem can be avoided
either by using multiple du commands or by using --count-links and
understanding that any totals and links may be overcounted.  If you
are confident this is the best way to go forward then I can live with
it.