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)