Subject: bin/5444: stat st_blocks miscalculation for large files?
To: None <gnats-bugs@gnats.netbsd.org>
From: Luke Mewburn <lukem@karybdis.cs.rmit.edu.au>
List: netbsd-bugs
Date: 05/12/1998 13:12:01
>Number: 5444
>Category: bin
>Synopsis: stat st_blocks seems wrong for large files
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: bin-bug-people (Utility Bug People)
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Mon May 11 20:20:00 1998
>Last-Modified:
>Originator: Luke Mewburn
>Organization:
NetBSD Foundation
>Release: NetBSD 1.3
>Environment:
NetBSD taipan.cs.rmit.edu.au 1.3 NetBSD 1.3 (TAIPAN) #3: Mon Mar 23 18:49:33
EST 1998 lm@taipan.cs.rmit.edu.au:/var/src/sys/arch/i386/compile/TAIPAN i386
>Description:
whilst examining a directory with some large files, i noticed
that 'ls(1) -s' appeared broken (showing an extremely large
number for the 'blocks' field, that was obviously wrong.)
initially this appeared to be a usual 32/64 bit type bug,
but after fixing the obvious problem in ls(1) (the code to
determine the width of the blocksize used 32bit types instead
of 64bit types), thing were still borken.
further investigation (by printing out the contents of
st_blocks and st_size) revealed that for the particular file
in question, st_blocks was way too large.
du(1) also gets things wrong.
>How-To-Repeat:
have a large file (around the 4GB mark). for example:
> ls -la uucp.logrot.022745
-rw-r--r-- 1 root wheel 4027703251 May 10 11:19 uucp.logrot.022745
> ls -s uucp.logrot.022745
18014398509222920 uucp.logrot.022745
> du uucp.logrot.022745
18014398509222920 uucp.logrot.022745
here's my hacked ls:
> ~/ls/ls -s uucp.logrot.022745
got uucp.logrot.022745, size 36028797018445840 4027703251
18014398509222920 uucp.logrot.022745
(the first number in the 'got' line is st_blocks, the second st_size)
$BLOCKSIZE is set to 1k; if I undefine it get:
> ls -s uucp.logrot.022745
36028797018445840 uucp.logrot.022745
>Fix:
unknown; it appears to be a kernel issue, as ls and du are
both affected, and i can't see anything obvious in the fts(3)
code that would affect st_blocks.
i have a gzipped copy of the file if a kernel hacker needs a
copy to extract (you'll need 3.75GB) to test with.
>Audit-Trail:
>Unformatted: