Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!bu-cs!bzs
From: bzs@bu-cs.BU.EDU (Barry Shein)
Newsgroups: comp.unix.wizards
Subject: Re: getcwd() and friends.
Message-ID: <30223@bu-cs.BU.EDU>
Date: 26 Apr 89 01:46:26 GMT
References: <3675@ficc.uu.net> <14689@rpp386.Dallas.TX.US> <811@mtxinu.UUCP> <2001@unisoft.UUCP> <3746@ficc.uu.net> <13563@ncoast.ORG> <10051@smoke.BRL.MIL> <13601@ncoast.ORG>
Followup-To: comp.unix.wizards
Organization: Boston U. Comp. Sci.
Lines: 34


I remember teaching a systems programming course and, after going over
the whole file system/file descriptor model getting into the SYSV
shmem/semaphore/msg stuff. At the end of the lecture I asked a student
who looked disturbed what the problem was, he said "it looks like it
landed on Unix after taking off from Mars!"

The (possibly true) story I had heard was the the whole interface was
thrown together by a non-mainline group to support a (possibly
internal) client at AT&T and ended up getting stuck in the mainline
distributions. That is, it was never a plan but an accident of history
somewhere back in the early SYSIII days.

I can't imagine what the nervousness is about having these things in
the file name space (not like anyone hesitated with FIFOs and that,
IMHO, is a neat feature.) They obviously all needed a global name
space and that's what the file system is there for.

I would have preferred some extension of "non-persistant" objects,
that is, file names (& inodes) which never leave main memory thus
guaranteed to go away in the event of a system crash, they only live
in the appropriate caches, only one bit needed in the buffer headers
and a little code to skip past them. Would have made all sorts of
objects like this cheaper and safer to implement (like lock files and
some types of temp files.)

Ah well, too late now I guess...

-- 

	-Barry Shein, Software Tool & Die

There's nothing more terrifying to hardware vendors than
satisfied customers.