[comp.sys.apple] ProDOS DESTROY problem?

AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") (02/28/89)

>Date:         Sat, 25 Feb 89 16:00:48 GMT
>From:         David Douthitt
>              <astroatc!nicmad!madnix!rat%speedy.wisc.edu@BRL.MIL>
>Subject:      Re: Hyper C
>
>[...] I then wrote a program KILL whose sole purpose was to make a
>DESTROY call to the Prodos MLI.  It too returned an Error #56.
>According to the Apple Prodos Technical Reference Manual and Beneath
>Apple Prodos, the DESTROY call does NOT return an error #56.
>
>Then I had a flash... I normally use Prodos v1.1.1 because of a
>modified QUIT code I had.  So, I thought, what if I use that Prodos
>v1.4 that I've been saving... lo and behold, the files deleted ok.
>
>Is this a Prodos BUG?  Sure sounds like it.  Of course, we're up to
>1.7 now are we not?

I've never seen a problem like that in _any_ version of ProDOS 8.
To me, it sounds like your _modified_ copy of ProDOS 1.1.1 was
messed up in an obscure way.  If you want to mail me a copy, I'll
compare it against an unmodified 1.1.1 and see if there are any
differences outside of the QUIT code.  Since I've never seen a bug
report on DESTROY in any ProDOS 8 release notes, I'd like to
duplicate the problem:  _if_ there really was a ProDOS bug, I want
to make sure it isn't still lurking around waiting to resurface
under the right conditions.

By the way, there have been very few bugs in most ProDOS 8 versions.
Starting with 1.2, there is support for the GS clock and for ProDOS 8
program to QUIT to ProDOS 16 programs on a GS.  Version 1.3 (of
ProDOS 8, not 16) had a serious bug (accidental use of a 65C02
instruction; Apple quickly corrected the problem by releasing P8
1.4).  Every time ProDOS 16 was revised, Apple had to release a new
version of ProDOS 8 because of the way they work together closely.
The current version is ProDOS 8 1.7 (on Apple IIgs System Disk 4.0).
Somewhere in there, a few changes were made:  the MLIACTV flag bug
was fixed (that bug was not present in 1.1.1, by the way), and
DESTROY was modified to swap the halves of index blocks rather than
zeroing them out.

There _was_ a bug under ProDOS 1.1.1 that would, under weird enough
circumstances (involving disk switching), cause fatal ProDOS error
number 0A to occur (I think that's the right number).

>======== David Douthitt :::: Madison, WI :::: The Stainless Steel Rat ========
>FidoNet: 1:121/1 or 1:121/2            {decvax|att}!
>UseNet:  ...{rutgers|ucbvax|harvard}!uwvax!astroatc!nicmad!madnix!rat
>ArpaNet: madnix!rat@cs.wisc.edu      {uunet|ncoast}!marque!

 --David A. Lyons              bitnet: awcttypa@uiamvs
   DAL Systems                 CompuServe:  72177,3233
   P.O. Box 287                GEnie mail:    D.LYONS2
   North Liberty, IA 52317     AppleLinkPE: Dave Lyons