Ah yes, the dreaded save with replace bug. It's strange how some people never encounter it and it is the bane of other people's existence. I ran into it a couple of times without knowing what had happened until I read about it in a magazine. Once you know about it, it's easy to avoid (or you could get JiffyDOS and never have to worry again). It was random enough that some people never encountered it and as a result there were long debates about whether it really existed or not.
In the end it will be as if nothing ever happened.
I have always heard that if you use the drive number, as in SAVE"@0:filename",8 that you will not get hit by the dread save-with-replace bug. I forget the reason.
Alan wrote:I have always heard that if you use the drive number, as in SAVE"@0:filename",8 that you will not get hit by the dread save-with-replace bug. I forget the reason.
The Wikipedia article on Commodore DOS states that using @0: was not effective in solving the save-and-replace bug.
It has been a long time so my recollection is a little fuzzy but I'm fairly sure the bug was only present in early 1541s as it was fixed once it was identified and it did not appear in later drives. As for JiffyDOS, I'm quite sure it does not have the bug. In fact, I remember an advert for JiffyDOS that specifically stated that the replacement ROMs "cured the 'save with replace' bug".
Last edited by gklinger on Thu Jan 11, 2007 1:57 am, edited 1 time in total.
In the end it will be as if nothing ever happened.
From what I remember, the drive first stores the file under a temporary name, then deletes the original file and renames the new one. This may not be related to the other save-with-replace bug, but in any case when the amount of free blocks is less than the expected program size, you might not want to use the @ method IIRC.
My old Vic-1540 drive had this same problem. In this one respect it was the worst of the drives I've had. It would trash the disk entirely if you tried to use SAVE@ at any time, and would trash disks at other times, too, such as when doing sequential writes.
I had tried having the store's tech replace the drive mech, to no avail, and eventually I had it swapped out under warranty and got a white 1541 that I still have. This drive still wouldn't save and replace, but at least it didn't trash disks as often.
I ended up writing a couple of disk recovery programs because of this problem. One would scan the disk surface and try to rebuild the BAM if that was all that appeared to be trashed. The other would painstakingly try to read off bad sectors until it got a good checksum, then would write it to another disk. I'd then go through the recovered sectors manually to see if they looked like they were really good as opposed to trash with complimentary errors. Both programs were slow, even by the standards of that time.
