TUHS

tuhs@tuhs.org

28 participants
6556 discussions

by Aharon Robbins

> 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

22 years, 2 months

question about V7 ls(1) vs. sys/stat.h and ls.c

by Kirk McKusick

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

22 years, 2 months

Re: [TUHS] sco v. ibm

by norman＠nose.cs.utoronto.ca

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

22 years, 2 months

The nameless horror of dotfiles [was (no subject)]

by Dennis Ritchie

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

22 years, 2 months

(no subject)

by Dennis Ritchie

> 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

22 years, 2 months

The nameless horror of dotfiles [was (no subject)]

by norman＠nose.cs.utoronto.ca

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?

22 years, 3 months

question about V7 ls(1) vs. sys/stat.h and ls.c

by Aharon Robbins

Greetings all. 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? When did the struct stat acquire the st_blocks member? 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? Thanks, Arnold Robbins

22 years, 3 months

Re: [TUHS] question about V7 ls(1) vs. sys/stat.h and ls.c

by msokolov＠ivan.Harhan.ORG

Chris Palmer <chris(a)nodewarrior.org> wrote: > What's with that "511" in there? To divide by N rounding up you first add N-1, then divide by N. MS

22 years, 3 months

Open Source Initiative response to SCO vs. IBM

by Aharon Robbins

A friend passed this URL on to me. I have not read it yet. Principal author is Eric Raymond. http://www.opensource.org/sco-vs-ibm.html Arnold

22 years, 3 months

sco v. ibm

by Phil Garcia

Hi, What do you make of the SCO (Caldera) lawsuit? Does it affect the archive in any way?

22 years, 3 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS