On 02/18/2013 12:18 AM, Elliott Forney wrote: > I find it unintuitive that the number in a line of output from > du does not necessarily reflect the size of the corresponding > directory or file.
That's been true forever. All versions of 'du' do that. For example, with Solaris 11 du: $ ls $ echo xxx >a/f $ ln a/f b/f $ du 16 ./a 8 ./b 32 . $ du a 16 a $ du b 16 b This sort of thing has been the normal behavior since the 1970s and it's unlikely that we'll want to change it now. > I find it surprising that the order of command-line arguments to > du may affect the output of du. Users don't expect this. Also, users might not expect that the order that directory entries are explored can affect the numbers that du outputs. It's the same thing. But we can't and shouldn't change the the directory-entry behavior; and this is an argument that we shouldn't change the behavior for command-line arguments as well. > Is it just me or does anyone else think this is convoluted? Yes, it's convoluted, but complexity is inherent to any file system that has hard links and where 'du' is supposed to count actual and not apparent disk usage. There's no way to escape this complexity entirely: it has to be reported to the user somehow. No matter what method 'du' uses, one will be able to construct confusing examples like the above. So the mere existence of examples that cause confusion is not sufficient evidence that we should change du's behavior.
