-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[please keep the list in the loop, and please don't top-post on technical
discussions]
According to Schwarz, Konrad on 11/11/2009 6:31 AM:
> Hello Eric,
>
> thanks for taking this up.
>
> Here is a session transcript that exhibits the bug:
>
> $ unset POSIXLY_CORRECT
> $ du test_sequence_1_1_ENF
> 56 test_sequence_1_1_ENF
> $ export POSIXLY_CORRECT
> $ du test_sequence_1_1_ENF
> 56 test_sequence_1_1_ENF
> $ POSIXLY_CORRECT=1
> $ du test_sequence_1_1_ENF
> 112 test_sequence_1_1_ENF
> $
>
> Note that the number of blocks changes only after POSIXLY_CORRECT has been
> set to one. POSIX mandates 512-byte blocks, Coreutils uses 1024-byte blocks
> by default.
Yes, your session demonstrates what looks like a bug, but I still don't
see how it is possible from the source. Are you sure you don't have other
variables set, such as DU_BLOCK_SIZE, BLOCK_SIZE, or BLOCKSIZE, which
might also be interfering?
The source code for block size, lib/human.c, uses:
return getenv ("POSIXLY_CORRECT") ? 512 : DEFAULT_BLOCK_SIZE;
which again does not care whether the POSIXLY_CORRECT variable is empty,
so I can't see where your behavior is coming from.
>
> Some version information:
>
> $ du --version
> du (GNU coreutils) 6.12
Have you tried this with coreutils 8.0?
> $ uname -a
> Linux mchn144c 2.6.27.29-0.1-default #1 SMP 2009-08-15 17:53:59 +0200 x86_64
> x86
> _64 x86_64 GNU/Linux
> $
>
> What else would you like to know?
>
- --
Don't work too hard, make some time for fun as well!
Eric Blake [email protected]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkr6v3kACgkQ84KuGfSFAYDhRgCfbNHANmiHh/BOjgkR7TPiyGcU
UhAAn1dbkSfuY7p+sNknQVoZE/lP1PEq
=xWYG
-----END PGP SIGNATURE-----
