Reason of Save-and-Replace bug? (split from: ROM calls and other tricks)

[Noizer]

Is there any way to scratch or overwrite these files? Specifically using string input from user for the filename.

You'd use the standard CBM DOS commands for this, e.g.:

OPEN15,8,15,"S0:"+N$:CLOSE15

deletes file N$ on disk.

You should *not* use the save-and-replace variant of the filename, i.e. prepend "@" or "@0:", as the implementation of this function is bugged on many 15xx disk drives and can corrupt the disk contents.

What’s the reason of the bug, where is the fault?

[Mike]

See here for a short explanation.

[Noizer]

See here for a short explanation.

I looked at it and new questions arose.
Is it possible to patch it?
As is known, the drive can be programmed nicely
Is 1541 II also affected?

[Mike]

Is it possible to patch it?

You can use the workaround I posted.

As is known, the drive can be programmed nicely

Not the SD2IEC, as counter-example. That type of drive in turn though wouldn't suffer from the bug - the maintainer of the sd2iec firmware had no heightened interest to make the behaviour of the SD2IEC drives also bug-for-bug compatible.

Is 1541 II also affected?

When I wrote about the 1541 in the older thread, that included all variants of it.

The main issue is this: you simply cannot use the "save-and-replace" command sensibly in own programs. There's always the possibility unsuspecting users will run your program on a drive that is affected by the bug, with a chance to corrupt the disk's contents. Just use the workaround, scratch the old file with the same name first and save the new file with the same name, and then you're fine.

If you are really concerned about data safety, you can extend that procedure as follows (this is particularly important for editors):

1. Save the new file with a temporary name,
2. *Then*, scratch the old file,
3. finally rename the file with temporary name so it now has the name of the old file.

That procedure can be extended further so an older version of the file is always kept as backup. Correct implementation left as exercise.

[srowe]

Suggested changes were made in an article in "The Transactor" Vol 7/2, I think a complete explanation of the issue was in an earlier edition.

[Edit] It was Issues 65 & 66 of "Compute!" magazine.

[Mike]

Suggested changes ...

These fixes invariably required the replacement of the DOS ROMs. Which alleviated the issue only for those people, who did that replacement. This didn't help those people with an original DOS ROM.

...

Unlike other buggy software, which maybe only crashed the computer, this bug always had the potential to destroy important data stored on disk. Just imagine someone having a game with save data and a text editor with text files stored on the same disk. Assume the text editor is doing it right - yet the game uses save-with-replace to update the save data. That action might corrupt the text files (and everything else on that disk as well) and only after some time the user will note the data loss and might even wrongly attribute it to the text editor.

Whether it is (or ever was) a good idea to store a game and a text editor on the same disk can be disputed, but disks were expensive those days ...

[Noizer]

I know about the destruction potential very well, lost some days of work. Reason why asking

[Noizer]

Suggested changes ...

These fixes invariably required the replacement of the DOS ROMs...

Found a simple software solution, portable.
https://ia802802.us.archive.org/19/item ... 85_Oct.pdf
See side 79. But, yes, Transactor magazine is interesting too

[Mike]

These two articles, "Save With Replace: Debugged At Last", Part 1 and Part 2 in "Compute!" issues #65 (Oct '85) and #66 (Nov '85) are very good sources. They explain in detail why the bug happens, how it can be triggered and how it affects the data on disk when it happens.

There's this paragraph near to the end of part 2 (see page 114) which sums up the findings:

Based on these findings, we recommend that you avoid the SAVE@ command when direct access channels to the drive are open or if you don't always specify the drive number in disk commands. You should also avoid SAVE@ when using programs or cartridges intended to speed up access on the 1541 disk drive. These programs often reserve internal drive buffers and may cause problems even if the drive number is specified. If you're using the DOS Wedge, we recommend issuing a >UI or >UJ command before each SAVE@ command to be sure all the buffer pointers are reset. Many word processors also allow you to send these commands to the drive. Otherwise, the drive should be turned off and then on before using SAVE@. (On the SX-64, press the drive reset button.)

Now, my own interpretation of this paragraph is as follows:

The successful operation of "save-and-replace" depends on factors that are not entirely under control of a program that uses it. It already suffices that the user did a rather benign LOAD"$",8 (without specifying drive number 0) to inspect the disk's contents before loading the program. That will already allocate the shadow buffer of (the non-existing) drive 1. A drive reset, whether in software (UI or UJ) or in hardware is not a sensible workaround, IMO. The option to manually send UI or UJ may not be available and in either case, the user has to remember that procedure every time. Embedding UI or UJ within the program code is *not* portable with regard to all drives! This is a complication the author of the article couldn't foresee though: on a 1581 or SD2IEC, a drive reset will change from a partition/sub-directory to the root, and thus the save might happen to another place as was intended by the user.

Again, the workaround for any new programs that I suggested - use scratch and then save instead of "save-and-replace" - always works, even on newer drives. Personally, I never use "save-and-replace", neither in direct mode and also not in my programs. When I use/test programs that are file editors in the widest sense I regularly do a peek inside the code, whether they use "save-and-replace": if I find it, that qualifies for a bug report.

[tokra]

I remember back in the day the machine-code-entering program of the german magazine 64er called "MSE" used the Save-and-Replace command which I found out the hard way after typing a lot of code in and loosing some other program on the same disk. I even made a patch so that MSE uses Scratch and Save but it was rejected by the magazine! Maybe at that time they didn't want to admit the bug since this was actually 4 or 5 years after they first published it.

[DrVeryEvil]

If you want to learn more about the SAVE@ bug on the 1541 drive, then look it up in the old Transactor magazines. In volume 6, issues 1 through 4, they address the issue and give the code to burn onto an EPROM to fix the problem.