bug-coreutils
[Top][All Lists]
Advanced

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]