### lft-1.3.5 README file

    See the file NEWS for a list of major changes in the current release.

    See the file INSTALL for compilation and installation instructions.

    Mail suggestions and bug reports for this program to leithy@ma.ultranet.com.

    This program suffers the same fate (for the same reason) as GNU du and ls.

    The following is excerpted from the GNU fileutils-3.16 README file
    for your edification.

    A warning about du for HP-UX users: GNU du (and I'm sure BSD-derived
    versions) counts the st_blocks field of the `struct stat' for each
    file.  (It's best to use st_blocks where available, instead of
    st_size, because otherwise you get wildly wrong answers for sparse
    files like coredumps, and it counts indirect blocks.)  Chris Torek in
    a comp.unix.wizards posting stated that in 4BSD st_blocks is always
    counted in 512 byte blocks.  On HP-UX filesystems, however, st_blocks
    is counted in 1024 byte blocks.  When GNU du is compiled on HP-UX, it
    assumes that st_blocks counts 1024-byte blocks, because locally
    mounted filesystems do; so to get the number of 512-byte blocks, it
    doubles the st_blocks value.  (The HP-UX du seems to do the same
    thing.)  This gives the correct numbers on HP-UX filesystems.  But for
    4BSD filesystems mounted on HP-UX machines, it gives twice the correct
    numbers; similarly, for HP-UX filesystems, du on 4BSD machines gives
    half the correct numbers.  GNU ls with the -s option has the same
    problem.  I know of no way to determine for a given filesystem or file
    what units st_blocks is measured in.  The f_bsize element of `struct
    statfs' does not work, because its meaning varies between different
    versions of Unix.