🚀 go-pugleaf

In article <140@kulcs.UUCP>, luc@kulcs.UUCP (Luc Van Braekel) writes:
>    Why is that command [@save] disk-corrupting ?  Is it unsafe just because if
>    something goes wrong during saving, your file is corrupted, or is
>    there more to it (like a bug in the drive o.s.) ?

There is a more serious problem then just trying to do a save with
replace when your disk is full.  There is a real bug in the DOS that
corrupts the disk on occasional save with replace commands. I've been
bitten three times (I'm a slow learner) and have finally completely
forsaken the command.  In my experience, the problem occurs when you
are using SAVE@ with two files.  Under some circumstances, when you do
a SAVE@ of file A, the directory entry is updated properly, but the BAM
is not updated.  You are now in trouble, but it is not obvious because
file A will load and list properly.  Presumably validating the disk at
this point would cure the problem.  If instead you load file B, edit
it, and then do a SAVE@ of file B, it will overwrite file A because the
space for A was not allocated in the BAM.  The end result is that the
directory entries for both A and B point to file B, and file A is
lost.

For more details and a demonstration of the bug see "SAVE with Replace
Exposed!!" in the July 1985 issue of The Transactor, and "Save with
Replace: Debugged at Last" in the October 1985 issue of Compute!.
The basic advice in Compute! is, "Therefore, the key to avoiding the
SAVE@ bug is to always specify drive 0 when performing any disk drive
function, or to always reset the drive before any SAVE@ operation."
Because I've forsworn this evil command, I can't verify that this
advice works.

					Don Gentner
					philabs!gentner@seismo.arpa