[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#10281: change in behavior of du with multiple arguments (commit
From: |
Paul Eggert |
Subject: |
bug#10281: change in behavior of du with multiple arguments (commit |
Date: |
Fri, 16 Dec 2011 23:41:20 -0800 |
User-agent: |
Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 |
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.
- bug#10281: change in behavior of du with multiple arguments (commit efe53cc), (continued)
bug#10281: change in behavior of du with multiple arguments (commit efe53cc), Elliott Forney, 2011/12/14
bug#10281: change in behavior of du with multiple arguments (commit, Paul Eggert, 2011/12/14
bug#10281: change in behavior of du with multiple arguments (commit, Alan Curry, 2011/12/16
bug#10281: change in behavior of du with multiple arguments (commit,
Paul Eggert <=
bug#10281: change in behavior of du with multiple arguments (commit, Alan Curry, 2011/12/17
bug#10281: change in behavior of du with multiple arguments (commit, Jim Meyering, 2011/12/17
bug#10281: change in behavior of du with multiple arguments (commit efe53cc), Elliott Forney, 2011/12/16
bug#10281: change in behavior of du with multiple arguments (commit efe53cc), Eric Blake, 2011/12/16
bug#10281: change in behavior of du with multiple arguments (commit efe53cc), Eric Blake, 2011/12/16
bug#10281: change in behavior of du with multiple arguments (commit efe53cc), Voelker, Bernhard, 2011/12/19
bug#10282: change in behavior of du with multiple arguments (commit efe53cc), Eric Blake, 2011/12/12