* [TUHS] V7 ls -s option
@ 2003-05-27 12:26 Aharon Robbins
2003-05-28 0:07 ` Greg 'groggy' Lehey
0 siblings, 1 reply; 4+ messages in thread
From: Aharon Robbins @ 2003-05-27 12:26 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* [TUHS] V7 ls -s option
2003-05-27 12:26 [TUHS] V7 ls -s option Aharon Robbins
@ 2003-05-28 0:07 ` Greg 'groggy' Lehey
0 siblings, 0 replies; 4+ messages in thread
From: Greg 'groggy' Lehey @ 2003-05-28 0:07 UTC (permalink / raw)
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>
^ permalink raw reply [flat|nested] 4+ messages in thread
* [TUHS] V7 ls -s option
2003-05-25 13:08 Aharon Robbins
@ 2003-05-26 4:16 ` Greg 'groggy' Lehey
0 siblings, 0 replies; 4+ messages in thread
From: Greg 'groggy' Lehey @ 2003-05-26 4:16 UTC (permalink / raw)
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>
^ permalink raw reply [flat|nested] 4+ messages in thread
* [TUHS] V7 ls -s option
@ 2003-05-25 13:08 Aharon Robbins
2003-05-26 4:16 ` Greg 'groggy' Lehey
0 siblings, 1 reply; 4+ messages in thread
From: Aharon Robbins @ 2003-05-25 13:08 UTC (permalink / raw)
> 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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2003-05-28 0:07 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-05-27 12:26 [TUHS] V7 ls -s option Aharon Robbins
2003-05-28 0:07 ` Greg 'groggy' Lehey
-- strict thread matches above, loose matches on Subject: below --
2003-05-25 13:08 Aharon Robbins
2003-05-26 4:16 ` Greg 'groggy' Lehey
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).