>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: