[BusyBox] bug#1158: can of worms

Larry Doolittle ldoolitt at recycle.lbl.gov
Fri Apr 27 17:20:03 UTC 2001


This bug report raises all sorts of other problems.
The "fix" as given is inadequate.

 -- a file size of 1.2K still comes out as 1.0K.

 -- du.c assumes stat.st_blocks are 512 bytes, and
    chops the fraction.  If run on a filesystem that
    can allocate single blocks (unlike ext2), a whole
    directory full of 400 byte files will show up as
    zero size.

 -- It doesn't seem right to need floating point (double
    or long double) computation in make_human_readable_str
    and df.c.

I know there have been long arguments on comp.unix.programmer
about whether or not stat.st_blksize*stat.st_blocks was _always_
an accurate rendition of the size of the file.  I _think_ it
is a safe bet on Linux.

Since du can cross file system boundaries, to really get the
right answer you would need to convert every file size to bytes
first (not the potentially filesystem-dependent st_blocks)
before summing.  I assume people want to avoid that to keep from
breaking at 4GB.  Maybe the way around this is to keep track
of the largest power of two which is a factor of all filesystem
block sizes seen so far.  Hmmm.

Would it help to add another argument to make_human_readable_str
that gave the "unit" size?  Then
  du.c could merrily add up the blocks, and give "512" as
  the unit at the end.
  df.c would be much more legible.
  ls.c would give "1" as the unit.
I volunteer to code a version of m_h_r_s that never overflows,
and doesn't use float.  It might look a little like the
computation in init.c/check_free_memory(), that is robust in
the face of a unit that is not even a power of two.  Or maybe
not.

     - Larry






More information about the busybox mailing list