Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site ucbvax.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!dillon
From: dillon@ucbvax.ARPA (The Sherif "Matt D.")
Newsgroups: net.micro.cbm
Subject: @REPLACE bug
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!