26 May
2003
26 May
'03
6:16 a.m.
On Sunday, 25 May 2003 at 16:08:02 +0300, Aharon Robbins wrote:
A block is a block. If it's allocated, it's all there (at least in
the Seventh Edition). It doesn't make any difference that some of the
space in the block may not represent valid data.
Greg
--
Finger grog(a)lemis.com for PGP public key
See complete headers for address and phone numbers
From: Dennis
Ritchie <dmr(a)plan9.bell-labs.com>
To: tuhs(a)minnie.tuhs.org
Subject: [TUHS] (no subject)
Date: Fri, 23 May 2003 00:10:30 -0400
Thanks for confirming this. In fact, the V7 calculation is only
an approximation in another sense; a file with large holes could
generate too large a result. The V7 ls(1) man page says that the -s option,
which prints total
blocks, includes any indirect blocks.
However, the V7 struct stat didn't have the
st_blocks member in the
struct stat, and the code in ls.c uses
long
nblock(size)
long size;
{
return((size+511)>>9);
}
So, is this just a case of the man page being
mistaken?
Yes, it looks like a manual bug. Retrieving
the true number of indirect blocks isn't possible
from the 7th edition stat. I'm not sure when (or by
whom) the st_blocks member was added.