A word about file integrity

[Matt_H]

I recently installed Final Copy II from ADF images I made some years ago. I found the program to be extremely buggy and crash-prone. This did not seem to be normal behavior, as other Softwood programs are very stable.

On a whim, I re-imaged the original disks and reinstalled the program by hand from the new ADFs. Now it appears to be rock-solid stable!

Even though my original ADFs and the new ADFs look identical in side-by-side DOpus listers via diskimage.device, something is clearly wrong with the original ADFs under the hood. I haven't looked at them in a hex editor/MD5sum yet, but I suspect that will reveal some differences.

I did the original ADFs in ADF-Blitzer, which offers no error checking/correction, and spits out a file of the correct size regardless of whether the operation was successful. I'm guessing it failed, but the resulting ADF was "good enough" to read and display file/directory information without throwing up an overt error message, and "good enough" for Final Copy to run, but with internal corruption that would send it quickly to Guru-town.

I've since moved my disk archiving operations (including my new Final Copy ADFs) over to TSGUI on my 4000T and SuperDiskImage/Catweasel on my AmigaOne XE. I wish I'd done so earlier! I've got nothing but praise for these programs - TSGUI has been able to recover perfect images from some very badly damaged disks.

Of course, now I'm worried about all the other disks I imaged with ADF-Blitzer...

[Matt_H]

@ QuickSanz

It's Thomas Rapp's program - it's on Aminet.

[Matt_H]

All I could think of is that ADF-Blitzer quietly ignores read errors while TSGUI informs the user and lets him choose to retry, ignore or abort. TSGUI can also be configured to automatically retry a certain number of times before the error requester appears.

That's it exactly. If it hits a track it can't read, ADF-Blitzer will abort (with no error message) and I guess it pads out the rest of the image with garbage data from RAM. That "Retry" option in TSGUI and SuperDiskImage makes all the difference!

Blitzer will often kick out quietly when it hits an issue. In using the software a lot I have gotten use to when the timing is out for the save and realise there is a problem. I often take disks I am suspiscious of into DOpus and manually copy to RAM and see how the files stack up. ADFBlitzer will copy over faulty files.

Indeed, I've done the same. In this case it must have failed on one of the later tracks so that I didn't realize it had stopped prematurely. But I had also assumed that if ADF-Blitzer failed in reading a complete disk then the disk was un-imageable. Not so! The other programs have saved disks that I thought were beyond hope. Do yourself a favor and retire ADF-Blitzer

@ thread

I ran the MD5 sums, and there were faults/mismatches in the original ADFs of the FCSystem_2.0 disk and FCMoreFonts disk. FCSystem must have been the cause of the instability problem, since that's the one that contains all the libs and binary support files. Mystery solved.