Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!hoptoad!tim
From: tim@hoptoad.uucp (Tim Maroney)
Newsgroups: comp.protocols.appletalk
Subject: Re: TOPS, AFP, et al
Message-ID: <7265@hoptoad.uucp>
Date: 12 May 89 20:14:46 GMT
References: <10660@ibmpcug.UUCP> <1865@ccnysci.UUCP> <939@smurf.ira.uka.de>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Eclectic Software, San Francisco
Lines: 47

In article <939@smurf.ira.uka.de> urlichs@smurf.ira.uka.de (Matthias Urlichs)
writes:
>Actually, one can use the range locking calls with TOPS. Unfortunately
>the TOPS people did several things wrong:

Not at all.  The TOPS implementation of PBLockRange is correct
according to the specification in Inside Mac volume IV.  Perhaps
you are simply unaware of how advisory locking works.

>- Program A opens a file, locks range x to y.
>  Program B opens the same file, reads that range _without_ locking it
>  first. Result under AppleShare: Program B gets an error result.
>  Result under TOPS: Program B can read (and write --> corrupt) the file.

That is correct.  AFP is incorrect.  Look up PBRead.  Do you see an
error return listed for "attempt to read locked range"?  No, eh?  How
about PBWrite?  No, eh?  Now look at PBLockRange.  It explicitly says
that you are supposed to call it immediately before PBRead.  If you
correctly lock down all ranges before reading or writing them, then you
can't corrupt the file.  That is how advisory locking synchronization
is supposed to work.

>- We now open a file, lock some bytes, close the file, open it again.
>  Wonder of wonders, the range is _still_ locked.
>(Disclaimer: This was true for version 1 of TOPS but if they had fixed it,
>FoxBase wouldn't have problems, so I assume it's still broken.)

No kidding.  Look again at the PBLockRange call.  You are required to
call PBUnlockRange ("be sure to call PBUnlockRange to free up that
portion of the file").  This is exactly what you'd expect of a locking
call that serves to synchronize multiple file descriptors.  Does
PBClose say anything about releasing locks by calling it?  No, eh?

The fact is that PBLockRange was designed by TOPS, and the TOPS
implementation was on the market long before the AppleShare
implementation was released.  The specification in Inside Macintosh
volume IV is for an advisory range locking mechanism which is more than
adequate for any application.  AFP changed the specification from that
in Inside Macintosh, after the TOPS implementation was already out; it
is broken, and anyone who relies on its behavior is broken.
Fortunately, it should be very easy for third party developers to come
around to the standard; I can only assume the reason FoxBase does not
do so is either laziness or ignorance.
-- 
Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim
"Don't talk to me about disclaimers!  I invented disclaimers!"
    - The Censored Hacker