Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site cmu-cs-speech2.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!godot!harvard!seismo!rochester!cmu-cs-pt!cmu-cs-speech2!jdr
From: jdr@cmu-cs-speech2.ARPA (Jeff Rosenfeld)
Newsgroups: net.micro.cbm
Subject: Re: save-replace bug on 1541
Message-ID: <204@cmu-cs-speech2.ARPA>
Date: Tue, 22-Jan-85 16:38:41 EST
Article-I.D.: cmu-cs-s.204
Posted: Tue Jan 22 16:38:41 1985
Date-Received: Sun, 27-Jan-85 04:52:44 EST
Organization: Carnegie-Mellon University, CS/RI
Lines: 15

One might also be careful of the fact that when the drive does a
save-replace, it writes the new file and THEN scratches the old version. If
filling up the disk during a write can foul up BAM, then a likely explanation
for the bug is that you don't have sufficient space on the disk for TWO
copies of your file. I have not had the problem using the save-replace
command (I use it constantly), but I have lost backup copies of some rather
large files that way. 
It may be useful to note that the VALIDATE command not only cleans up
"poisoned" blocks, but also reallocates the disk space so that blocks that
are allocated but unused  can be freed for re-use. These unused blocks become
allocated through continued use of the save-replace command. It is therefore
a pretty good idea to VALIDATE your disks every so often.

                                           - Jeff Rosenfeld.
                                             jdr@cmu-cs-speech2.ARPA