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

[Paul Eggert]

On 12/16/11 18:36, Alan Curry wrote:
> The straightforward method would be to simply the directory you intend to
> remove and keep track of the discrepancy between st_nlink and how many links
> you've seen.

Sorry, I can't parse that.  But whatever it is, it sounds like you're
talking about what one could do with a program written in C, not with
either GNU or Solaris du.

> As a creative improvised use of pre-existing tools it's a good example, but 
> as a
> justification for an intentional feature, it's just too inefficient.

I'm having trouble parsing that as well but will try to answer anyway. :-)

First, the use of 'du' in the way I'm describing
is not particularly creative or improvised.  I use it
often in link farms (i.e., directories containing many
multiply-linked files).  And it's no accident that Git encourages link
farms either: the Git maintainer is a former coworker of mine,
and even before Git existed we used link farms a lot during software
development, and needed tools like 'du' to work well in link farms,
and this is partly why GNU 'du' works the way it does.  In short,
what may have appeared to you to be an accidental use of 'du'
is actually a designed one.

Second, I don't see what efficiency has to do with this, because exactly
the same efficiency issue arises with Solaris du, when it is given
a different argument list.  With Solaris du, I can get essentially
the same output as GNU "du A B C" by temporarily modifying the file
system, as follows:

 $ mkdir tmp
 $ mv A B C tmp
 $ (cd tmp; du; mv A B C ..)
 $ rmdir tmp

Of course I'd never want to do that in an actual link farm: it's tricky
and brittle and could mess up currently-running builds.  But the point is that
GNU du is not being inefficient here, any more than Solaris du is.