[TUHS] V7 ls -s option

[TUHS] V7 ls -s option

[Aharon Robbins]

> From: Dennis Ritchie <dmr at plan9.bell-labs.com>
> 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.

System III doesn't have st_nblocks either.

>  > While I'm at it, the V7 ls -a option only adds . and .. to the
>  > list; apparently all other dot files were printed by default.
>  > When did ls change such that -a applied to all dot files?
>
> UCB or USL did this (I'm sure which first).
> Both tended to use more . files.
>
> 	Dennis

As already pointed out, earlier Research code only checked the
first character for being '.'; I later looked at the V6 ls.c.

The System III ls.c is essentially the V7 one, but with comments
added, and -l printing both owner and group, with -g and -o to
turn off group or owner from -l.  Also, support for FIFOs.

The nblock() calculation is considerably more complicated, and
would seem to actually get the number of indirect blocks. At
first glance, it looks though like a file with holes would
still confuse it.

Nothing like engaging in Software Archeology... :-)

Thanks,

Arnold

[TUHS] V7 ls -s option

[Greg 'groggy' Lehey]

On Sunday, 25 May 2003 at 16:08:02 +0300, Aharon Robbins wrote:
>> From: Dennis Ritchie <dmr at plan9.bell-labs.com>
>> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20030526/8b5dcf53/attachment.sig>

[TUHS] V7 ls -s option

[Greg 'groggy' Lehey]

On Tuesday, 27 May 2003 at 15:26:24 +0300, Aharon Robbins wrote:
> The V7 ls.c code:
>
>>>>> 	long
>>>>>	nblock(size)
>>>>>	long size;
>>>>>	{
>>>>>		return((size+511)>>9);
>>>>>	}
>>>>
>
> I wrote:
>
>>> In fact, the V7 calculation is only
>>> an approximation in another sense; a file with large holes could
>>> generate too large a result.
>
> Greg 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.
>
> You're missing my point.  Consider a C program along these lines:
>
> 	int main(void)
> 	{
> 		int fd = creat("/some/file", 0600);
>
> 		lseek(fd, 123456789L, 0);	/* absolute seek */
> 		write(fd, "x", 1);
> 		close(fd);
> 	}
>
> After running this program, the `/some/file' file now looks rather
> large. But it only has one block allocated to it.  However, the V7
> nblock() function computes a number somewhat larger than one.

Yes, I missed your point.  Sorry.  This is what comes of shooting off
my mouth before reading the code.

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20030528/233ac556/attachment.sig>

[TUHS] V7 ls -s option

[Aharon Robbins]

The V7 ls.c code:

> >>> 	long
> >>>	nblock(size)
> >>>	long size;
> >>>	{
> >>>		return((size+511)>>9);
> >>>	}
> >>

I wrote:

> > In fact, the V7 calculation is only
> > an approximation in another sense; a file with large holes could
> > generate too large a result.

Greg 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.

You're missing my point.  Consider a C program along these lines:

	int main(void)
	{
		int fd = creat("/some/file", 0600);

		lseek(fd, 123456789L, 0);	/* absolute seek */
		write(fd, "x", 1);
		close(fd);
	}

After running this program, the `/some/file' file now looks rather
large. But it only has one block allocated to it.  However, the V7
nblock() function computes a number somewhat larger than one.

Thanks,

Arnold