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