Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site u1100s.UUCP
Path: utzoo!watmath!clyde!cbosgd!cbdkc1!desoto!cord!hudson!bentley!hoxna!houxm!whuxl!whuxlm!spuxll!abnji!u1100a!u1100s!sjs
From: sjs@u1100s.UUCP (Stan Switzer)
Newsgroups: net.arch
Subject: Magic Cookies and File Systems
Message-ID: <190@u1100s.UUCP>
Date: Mon, 4-Mar-85 09:17:14 EST
Article-I.D.: u1100s.190
Posted: Mon Mar  4 09:17:14 1985
Date-Received: Thu, 7-Mar-85 04:06:54 EST
References: <917@sjuvax.UUCP> <538@rlgvax.UUCP>
Reply-To: sjs@u1100s.UUCP (Stan Switzer)
Organization: Bell Communications Research, Piscataway, NJ
Lines: 38
Summary: 

[ does this really belong in net.arch? ]

In article <538@rlgvax.UUCP> guy@rlgvax.UUCP (Guy Harris) writes:
> > The problem lies in picking an underlying model sufficiently robust
> > to do all of the things you want to do with record and file locking, ...
> 
> Well, several UNIX versions *do* have record and file locking - System V
> Release 2 Version 2, for one.  They are based on John Bass' byte-stream
> locking mechanism; you lock a given range of bytes in the file.
> 
> VMS, on the other hand, has a locking mechanism that locks magic cookies;
> cooperating applications agree on a name for a resource and they lock
> that name when they want to lock that resource. ...
> ...
> This means you can lock things other than files; perhaps locking should
> have nothing to do with the file system.

On the contrary, all magic cookies should be tied to the file system in
some way.  It really burns me the way some message passing, locking,
and semaphore systems use a globally administered pool of names (or
worse yet, numbers!!) for the names of entities.  The file system directory
structure is the ONLY logical place for global names of ANY kind to reside.

UNIX drew on this idea from MULTICS, and used it to good advantage.  As in
MULTICS, devices and executable programs are just a particular kind of
enrty in the file system.  In MULTICS it went further: memory, in fact
everything, was named in the file system.

Actually I agree about locking resources, but locking ranges of bytes in
files is useful too.  Anyway, for the purpose of locking resources, you
just need a file (special or otherwise) to represent a resource, and you
do your locking against that file.

IF SOMETHING NEEDS A NAME, PUT IT IN THE FILE SYSTEM!!!!!!!!!!!!!!!

--------------------------------------------------------------------------
Stan Switzer     |  "We're gonna have a TV party tonight.
ihnp4!u1100s!sjs |   Alright!"  -- Black Flag