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