Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!mcvax!unido!iraun1!smurf!urlichs
From: urlichs@smurf.ira.uka.de (Matthias Urlichs)
Newsgroups: comp.protocols.appletalk
Subject: Re: TOPS, AFP, et al
Message-ID: <946@smurf.ira.uka.de>
Date: 17 May 89 21:41:09 GMT
References: <939@smurf.ira.uka.de> <7265@hoptoad.uucp>
Reply-To: urlichs@smurf.ira.uka.de (Matthias Urlichs)
Organization: University of Karlsruhe, FRG
Lines: 110

In comp.protocols.appletalk tim@hoptoad.UUCP (Tim Maroney) writes:
< In article <939@smurf.ira.uka.de> I write:
< >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.
< 
Yes I do know how advisory locking works. Studying a few semesters of CS
_does_ give you some insights on how things work.
But the question is, is it _advisory_ or _mandatory_ locking?
Methinks it's the latter. For reasons, see below.

< >- 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

I do not see an error "range already locked" in the paragraph describing
PBLockRange, either.
(Disclaimer: I have the Beta draft of IM IV here.)
"Range already locked" et al., are AFP error codes, all of which have been
added to the File manager calls (in a general way) via the "applications in a
shared environment" document.

< that you are supposed to call it immediately before PBRead.  If you
Sorry, it says that you can use the same parameter block for PBLockRange
and PBRead if you call the one immediately before the other.

< 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.

But it says "When you're finished with the data (...), be sure to call
PBUnlockRange to free up ... for subsequent PBRead calls."
Which suggests to me that mandatory locking is exactly what is intended here,
which is what AppleShare does, and Tops does not do.
The same thing is explicitly stated in Inside AppleTalk, AFP section,
in the "Overview of AFP calls" chapter. ("... [Locking a range] reserves ...
[that range] for exclusive manipulation by the client placing the lock.")
< 
< >- We now open a file, lock some bytes, close the file, open it again.
< >  Wonder of wonders, the range is _still_ locked.
< 
< 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?
< 
These range locks are associated with an access path, and if that
access path is closed, there's no way to unlock them any more.
Besides, whatever do I need a range lock for if I can't get at the data
anyway? So I would certainly assume that the locked ranges get unlocked,
regardless of whether Inside My says it is, or not. And IM IV certainly
does NOT say that the locked range is NOT unlocked autmatically.

If the locks were kept in place, they would serve not file descriptors,
but files, for which I do not need byte level locking.

< The fact is that PBLockRange was designed by TOPS, and the TOPS
"jointly by Centram and Apple" it says (in Inside AppleTalk).
If Centram then says "this is fine with us but we'll go and do our own stuff"
I would not assume that anything they do after such a move would be consistent
with any standard...
< 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.

Well...
- The sentence in Inside Mac IV that _I_ saw (quoted above) leads me
  to assume that it's not just advisory locking. Instead it seems to say
  that a locked range can't be accessed by PBRead, which is all I need
  to know to see it's mandatory. :-)
  The AFP standard explicitly states this.
  Where did you see the word "advisory"?
- The standard seems to be AFP and not TOPS. At least to Apple it is,
  and that's what counts in the long run.

Additionally, mandatory locking makes more sense anyway because
- With mandatory locking I can allow multiple readers to access a given range
  concurrently. This is not possible with advisory locks because
  I'd have to lock the range to make sure it is in a consistent state.
- Advisory locking generates lots of additional network traffic because
  when reading something, I have to lock, read, then unlock.

< 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.

Or, as I described above, they did not want to look at whether TOPS or AFP
was running the server, and/or were concerned about network traffic,
or simply didn't want to bother with TOPS. I could understand that. (1/2 :-)

To the other netlanders: I apologize to everyone if it seems like we're
bashing at each other, TOPS, AFP, Inside Mac, et al. here.
PS: Anybody at Apple listening? Care to enlighten us in these matters? :-)
Tim: We'd better continue this discussion via mail (only if you still disagree,
of course :-), and then post if/when we've come to an agreement...
-- 
Matthias Urlichs -- Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- FRG
urlichs@smurf.ira.uka.de -- ++49+721-621127@PTT