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!ihnp4!houxm!whuxl!whuxlm!akgua!sdcsvax!sdcsla!gentner
From: gentner@sdcsla.UUCP (Don Gentner)
Newsgroups: net.micro.cbm
Subject: Re: Oh, no! Not the "SAVE/REPLACE" Bug!
Message-ID: <812@sdcsla.UUCP>
Date: Thu, 7-Mar-85 15:26:12 EST
Article-I.D.: sdcsla.812
Posted: Thu Mar  7 15:26:12 1985
Date-Received: Sun, 10-Mar-85 05:29:23 EST
References: <485@ssc-vax.UUCP>
Distribution: net
Organization: U.C. San Diego, Cognitive Science Lab
Lines: 19

> 

I agree with you, Ron.  The three times I was bitten by save/replace
(I'm a slow learner), I was saving moderate size programs on disks that were
less than half full.  There was plenty of room for temporary copies.

You say that when you tried to load a 4 block file, an entirely different
20 block file came up.
Now I predict that you first did a save/replace on your 4 block file, and
next did a save/replace on your 20 block file.  Further, if you look at
your directory block, you will find that the directory entries for both
files have a pointer to the same block (the start of the 20 block file).
My guess is that for some reason, the BAM was not updated properly when you
saved the 4 block file and thus it was overwritten by the later save.
I've tried examining broken disks without getting any closer than this to
the root problem, but perhaps someone will have more luck.

				Don Gentner
				CSL, UC San Diego