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
I haven't come up to speed yet on SCOIBM Wars (pronounce it as you
like, but perhaps not in polite company), but even so I know enough
to ask a question: is anyone in possession of a signed, original,
genuine, non-electronic copy of the Bill Broderick letter of 23 Jan 2002
that granted a mostly free license (as long as credit given and Caldera's
name not used in vain) for 32V, V7, and predecessors?
Certainly there are electronic copies around; it existed (perhaps still
exists) as a PDF file on Caldera's web site. I have a hardcopy in my
own files, next to the old SCO Ancient UNIX Source Code agreement for
which I paid hard cash (as we used to call the US dollar). But if there
is an original somewhere, that might carry more weight.
Is Bill Broderick still in an appropriately high position at Caldera
or SCO?
Norman Wilson
Toronto ON
All,
At 7am on Saturday 31st May (local time), the machine which runs
this mailing list will be temporarily shut down as major power and UPS
alterations are done in the machine room. I am informed that this should
only take 12 hours, but you know what computers and such are like.
Therefore, you should expect that this mailing list will be unavailable
over the weekend of the 31st May / 1st June.
Normal services will be resumed shortly :-)
Cheers,
Warren
All,
At 7am on Saturday 31st May (local time), the machine which runs
this mailing list will be temporarily shut down as major power and UPS
alterations are done in the machine room. I am informed that this should
only take 12 hours, but you know what computers and such are like.
Therefore, you should expect that this mailing list will be unavailable
over the weekend of the 31st May / 1st June.
Normal services will be resumed shortly :-)
Cheers,
Warren
> 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
>
> > 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
The st_blocks field was first added to the stat structure in 4.2BSD
(4.1b really) as part of the overhaul to add the new filesystem. I
added it because the variable filesystem blocksize made it difficult
to compute the amount of storage dedicated to a file.
Kirk McKusick
T. M. Sommers:
If [Broderick] was [SCO's or Caldera's] agent, then it doesn't matter what
they claim to recognize now; they are bound by his statement.
Assuming it can be proven that the statement was officially made,
which is why I ask after properly signed hardcopy rather than the
PDF file we have all seen.
Probably there are documents hidden away in SCO's files--there must
have been some paper trail leading to Broderick's letter--but that
is likely to be harder to track down from outside.
I don't doubt Broderick really wrote that letter, nor that he was
authorized to make the statement. But the problem before us isn't
truth, it's proof.
Norman Wilson
Toronto ON
The omniscient Norman seems to have nailed me:
> Judging by the manuals, Research did it first. In every manual from
> 1/e to 6/e, the entry for ls(I) has this description for the -a option:
> list all entries; usually those beginning with "." are suppressed
I suspect that in v7 (where .thing was indeed listed by default)
we decided that since .thing was a real file in the
directory it was better to list it instead of hiding it
by default. (Seeing . and .. seemed seldom interesting,
however).
I was solely (and much more recently) responsible for the lack
of subject header in my earlier reply.
Dennis
> 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.
> 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
Dennis Ritchie, on ls discarding all names beginning with .:
UCB or USL did this (I'm sure which first).
Both tended to use more . files.
Judging by the manuals, Research did it first. In every manual from
1/e to 6/e, the entry for ls(I) has this description for the -a option:
list all entries; usually those beginning with "." are suppressed
I always thought this was just a quick-and-dirty way to skip the . and ..
entries; the sort of shortcut that was common in the good old days when
everything was written in assembly language.
That the USL system kept the old convention probably reflects its PWB
heritage; both the latter system and that of Berkeley had already invented
lots of configuration files clumsily hidden by putting . at the beginning--
more than ls had options at the time--and I guess they felt it was better
to let sleeping dots lie.
Incidentally, in 1/e ls(I) had a whopping five options: l, t, a, s, and d,
each with the same meaning as now (except that -s is described simply as
`give size in blocks for each entry' with nothing about accounting for
indirect blocks or other overhead). Who says we haven't made decadence,
er, progress over the years?
Norman Wilson
Toronto ON
PS: I've lost track. Did the original Subject: line of this thread of
conversation get lost because it began with a dot?
