From mboxrd@z Thu Jan 1 00:00:00 1970 From: grog@lemis.com (Greg 'groggy' Lehey) Date: Mon, 26 May 2003 13:46:34 +0930 Subject: [TUHS] V7 ls -s option In-Reply-To: <200305251308.h4PD82YW011475@localhost.localdomain> References: <200305251308.h4PD82YW011475@localhost.localdomain> Message-ID: <20030526041634.GR15770@wantadilla.lemis.com> On Sunday, 25 May 2003 at 16:08:02 +0300, Aharon Robbins wrote: >> From: Dennis Ritchie >> To: tuhs at minnie.tuhs.org >> Subject: [TUHS] (no subject) >> Date: Fri, 23 May 2003 00:10:30 -0400 >> >>> 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. > > 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. 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 at lemis.com for PGP public key See complete headers for address and phone numbers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: