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.
