Message-ID: <4051@ucbvax.ARPA>
Date: Sun, 6-Jan-85 20:41:15 EST
Article-I.D.: ucbvax.4051
Posted: Sun Jan  6 20:41:15 1985
Date-Received: Mon, 7-Jan-85 07:42:26 EST
Distribution: net
Organization: University of California at Berkeley
Lines: 49




       A couple of people have asked about the @:replace bug in commodore DOS.
Here is a brief rundown on what I know about it...

       Commodore users have long complained of a bug in the "@:replace"
command. They claimed that the directory would get messed up, and files
would suddenly become other files (most anoying!). On the other hand, some
BBS owners have used the @:replace command for years without incident.


       Unfortunately in my extensive re-writing of the 1541 DOS I did not
find any problem. IT SHOULD WORK FINE! (1541 Flash! owners please ignore
what I said about the bug in the manual-that was wrong). I have however
found two cases when @:replace WILL misbehave:


1>  The way the command works is to first note in the directory that the file
is open for replace. It saves the new file. Then it scratches the old file.
And finally it closes the new file, pointing to the new first link.

    If there was not enough room on the disk to save the file (step 2) then,
rather than give a "Disk Full Error" or something sensible like that it puts
the parts of your file that would not fit on the disk into WOM (write only
memory). Kiss your file goodbye!      *Never* @:save to a full disk.


2>  If you happen to @:replace a invalid file "*PRG" on a 2040,4040 or 2030 the
drive is not quite smart enough to figure out that file is invalid and will
link through the invalid file to scratch it, possible causing files to overlap,
become misnamed etc (sound familiar??).
     However on the 1541 a invalid file is checked for, so this should not
happen ever. Nevertheless *NEVER* @:replace or scratch a invalid file. Save the
data if you want it (",P,M") then Validate the disk.


          So there you have nothing. The operator of the SFCUG BBS has used
@:replace for 2 years; other than the fact that his read/write heads look like
they had a fight with a piece of sandpaper, he has had no problems. Others
use @:replace and have problems. You decide.

          -Bryce Nesbitt of 1541 Flash!-


P.S.  About two moths ago I decided to be brave, make *lots* of extra backups
and start using @:replace regularly. I have had no trouble as of yet!

Message-ID: <757@sdcsla.UUCP>
Date: Mon, 7-Jan-85 14:57:26 EST
Article-I.D.: sdcsla.757
Posted: Mon Jan  7 14:57:26 1985
Date-Received: Fri, 11-Jan-85 08:08:11 EST
References: <4051@ucbvax.ARPA>
Distribution: net
Organization: U.C. San Diego, Cognitive Science Lab
Lines: 19

The legendary @:replace bug really exists, at least on some 1541
drives.  I have a 1541 drive purchased in August 1983, over the first
six months of moderately frequent use I was bitten 3 times, before I
learned my lesson.

Here is the pattern.  I would save file A with @:replace, then check it
and it would be fine.  Then I would load file B, do some editing, then
save file B with @:replace.  At this point, file B is fine, but file A
is lost.  The directory listing looks fine, but if I try to load file A,
I get file B (If I load file B, I also get file B).  Looking at the
directory block on the disk, I find everything reasonable, except that
the entries for file A and file B both point to the same initial
block.  My guess is that under some rare conditions, the BAM is not
updated properly (when file A was written) to indicate that the space
is used, and file B is written over file A.

			Don Gentner
			UC San Diego
			(gentner@nprdc or ucbvax!sdcsvax!sdcsla!gentner)