urlichs@smurf.ira.uka.de (Matthias Urlichs) (05/09/89)
In comp.protocols.appletalk alexis@ccnysci.UUCP (Alexis Rosen) writes: < < In article <gYK=wvy00WB7AiCG93@andrew.cmu.edu> dp22+@andrew.cmu.edu < (David Bruce Pinkus) writes: < > Has anybody had any success using the Multi-User version of FoxBase < >with TOPS? I haven't seen the Multi-user version, but if it can be done, < >I'd appreciate some advice/info. < < TOPS does not support AFP, and will therefore not support Fox. In fact, as far < as I can determine from lengthy discussions with TOPS tech types, TOPS does < not support any kind of byte-range or record locking whatsoever. (This is why < 4D tends to crash more frequently under TOPS than AppleShare or single-user: < It knows it's not getting AFP so it does some bogus page-locking instead.) < Fox chose not to do it at all rather than do it wrong. < Actually, one can use the range locking calls with TOPS. Unfortunately the TOPS people did several things wrong: - 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. - 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.) < TOPS claims that they will support the byte-range locking features of AFP < by the end of the year. This would make them compatible with FoxBase. :-) :-) :-) If they need that much time to put a thing like that into their protocol (just checking for locked ranges on _Read and _Write, right?) then they do have some very serious problems. They should have even less of a problem under System 7 (apart from getting TOPS to work at all, of course :-) if/when the Mac OS supports range locking for local disks. APPLE, PLEASE DO IT! < < It is my carefully considered opinion that TOPS is in the same position now < that MacServe was in three years ago: They currently dominate the market, < and they're throwing it all away through marketing stupidity and bad < technological decisions. I expect to see TOPS dwindle to a small minority < of the market within 24 months. Guess how hard it is to write an AppleShare server to run under MultiFinder (or as a driver) concurrently with your normal work? Expect to see such a beast "soon". (Whenever that may be.) What you won't get is password protection on a per volume basis (the way TOPS does it). AFP provides the framework for it, but the AppleShare client for the Mac does not implement it. :-( Guess how much faster than TOPS such a beast would be? :-) -- Matthias Urlichs -- Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- FRG urlichs@smurf.ira.uka.de -- ++49+721-621127@PTT
tim@hoptoad.uucp (Tim Maroney) (05/13/89)
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
urlichs@smurf.ira.uka.de (Matthias Urlichs) (05/18/89)
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@PTTandrews@Apple.COM (Richard Andrews) (06/07/89)
>>But the question is, is it _advisory_ or _mandatory_ locking? >>Methinks it's the latter. >>PS: Anybody at Apple listening? Care to enlighten us in these matters? Yes, we were listening. Allow me to set the record straight. Byte range locking in AFP is mandatory. Before reading or writing a range, you must lock it, otherwise the read or write operation could fail with a RangeLocked error. Locking a range reserves it for your exclusive use. When you are finished using the range, you should call UnlockRange. However, if you don't, all the ranges you locked with a given refnum will be unlocked when you issue a Close call with that refnum. Rich Andrews