Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: Notesfiles $Revision: 1.6.2.17 $; site uiucdcsb.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!ihnp4!inuxc!pur-ee!uiucdcsb!miller From: miller@uiucdcsb.UUCP Newsgroups: net.micro.cbm Subject: Re: save-replace bug on 1541 Message-ID: <16800019@uiucdcsb.UUCP> Date: Fri, 11-Jan-85 16:15:00 EST Article-I.D.: uiucdcsb.16800019 Posted: Fri Jan 11 16:15:00 1985 Date-Received: Sat, 12-Jan-85 08:27:13 EST References: <310@snow.UUCP> Lines: 13 Nf-ID: #R:snow:-31000:uiucdcsb:16800019:000:680 Nf-From: uiucdcsb!miller Jan 11 15:15:00 1985 If that were true, then the problems would occur in the data sectors on the disk as they were overwritten using the old BAM. Instead, the problem arises in the directory as the start of file pointer gets smashed on an innocent (and in my cases, directory contiguous) file. Furthermore, your hypothesis would lead to many files all getting smashed at random since another disk's BAM is being used to allocate sectors. Instead, only one file (at a time) gets lost. I think the jury is still out on the cause of the 1541 @replace bug. If anyone "really" comes up with the cause, then you should be able to repeat it by duplicating the configuration. A. Ray Miller Univ Illinois