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