Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!think!nike!ll-xn!adelie!axiom!linus!philabs!briar!drg
From: drg@briar.UUCP (Don Gentner)
Newsgroups: net.micro.cbm
Subject: Re: 1541 diskdrive questions
Message-ID: <394@briar.UUCP>
Date: Wed, 1-Oct-86 08:24:55 EDT
Article-I.D.: briar.394
Posted: Wed Oct  1 08:24:55 1986
Date-Received: Sat, 4-Oct-86 05:36:23 EDT
References: <140@kulcs.UUCP>
Organization: Philips Laboratories, Briarcliff Manor, NY
Lines: 31
Summary: save with replace bug

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