[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RFC: do you use du --bytes (-b) [Re: 'du -b' bug in fileutils-4.1
From: |
Jim Meyering |
Subject: |
RFC: do you use du --bytes (-b) [Re: 'du -b' bug in fileutils-4.1 |
Date: |
Thu, 20 Feb 2003 17:01:40 +0100 |
Thank you for reporting that.
It looks like I made that change over 5(!) years ago.
And as far as I recall, you're the first to mention it.
Here's the ChangeLog entry:
Sun May 25 09:21:01 1997 Jim Meyering <address@hidden>
...
* src/du.c: Remove global variable opt_human_readable.
...
(count_entry): Always count in units of 512-byte blocks to delay.
This lets du accumulate totals corresponding to a terabyte before
overflowing 32-bit long int.
Use print_size instead of open coding it.
The above comment about the limitation of `32-bit' types is no longer
pertinent, since these days. the sums should be computed in 64-bit variables
(of type uintmax_t) on all systems.
I can see a few ways to handle this:
1) Accumulate counts of bytes, rather than counts of blocks
so that `du --bytes' works like it did back in fileutils-3.16.
Would anyone mind being limited to totals < 2^64 bytes? :-) 1/2
2) Leave the code the way it is and document clearly
that --bytes (-b) is equivalent to --block-size=1
3) Like 1), but make the printing of individual byte counts
dependent on a new option.
Do any of you know of applications that use du's --bytes (-b) option?
David, how is the old functionality of `du -b' useful to you?
I've redirected to bug-coreutils.
Comments welcome.
Jim
David Eisner <address@hidden> wrote:
> Hi. I think there's a bug in the 'du' utility in fileutils-4.1.
>
> du -b is supposed to report the size of the file in bytes.
> The observed behavior is that du -b reports the size rounded
> up to the nearest multiple of 1024, however:
>
> venice[ /venice/cradle ]% ls -l file.dat
> -rw-rw-r-- 1 cradle calce 417 Feb 19 18:29 file.dat
> venice[ /venice/cradle ]% fileutils-4.1/bin/du -b file.dat
> 1024 file.dat
>
> The expected behavior is that du -b report '417' as the size.
>
> The problem seems to have been introduced in fileutils-4.0:
>
> venice[ /venice/cradle ]% ls -l file.dat
> -rw-rw-r-- 1 cradle calce 417 Feb 19 18:29 file.dat
> venice[ /venice/cradle ]% fileutils-3.16/bin/du -b file.dat
> 417 file.dat
> venice[ /venice/cradle ]% fileutils-4.0/bin/du -b file.dat
> 1024 file.dat
> venice[ /venice/cradle ]% fileutils-4.1/bin/du -b file.dat
> 1024 file.dat
>
>
> The problem is in the count_entry() function in du.c:
>
> 507
> 508 size = ST_NBLOCKS (stat_buf);
> 509 tot_size += size;
> 510
>
> but in v3.16, we have:
>
> 514 if (output_size == size_bytes)
> 515 size = stat_buf.st_size;
> 516 else
> 517 size = ST_NBLOCKS (stat_buf);
> 518
> 519 tot_size += size;
...
- RFC: do you use du --bytes (-b) [Re: 'du -b' bug in fileutils-4.1,
Jim Meyering <=