Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site sdcsla.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxj!houxm!whuxlm!akgua!sdcsvax!sdcsla!gentner
From: gentner@sdcsla.UUCP (Don Gentner)
Newsgroups: net.micro.cbm
Subject: Re: @REPLACE bug
Message-ID: <757@sdcsla.UUCP>
Date: Mon, 7-Jan-85 14:57:26 EST
Article-I.D.: sdcsla.757
Posted: Mon Jan  7 14:57:26 1985
Date-Received: Fri, 11-Jan-85 08:08:11 EST
References: <4051@ucbvax.ARPA>
Distribution: net
Organization: U.C. San Diego, Cognitive Science Lab
Lines: 19

The legendary @:replace bug really exists, at least on some 1541
drives.  I have a 1541 drive purchased in August 1983, over the first
six months of moderately frequent use I was bitten 3 times, before I
learned my lesson.

Here is the pattern.  I would save file A with @:replace, then check it
and it would be fine.  Then I would load file B, do some editing, then
save file B with @:replace.  At this point, file B is fine, but file A
is lost.  The directory listing looks fine, but if I try to load file A,
I get file B (If I load file B, I also get file B).  Looking at the
directory block on the disk, I find everything reasonable, except that
the entries for file A and file B both point to the same initial
block.  My guess is that under some rare conditions, the BAM is not
updated properly (when file A was written) to indicate that the space
is used, and file B is written over file A.

			Don Gentner
			UC San Diego
			(gentner@nprdc or ucbvax!sdcsvax!sdcsla!gentner)