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...

[orange]

strange that OS didn't complain. OFS should have some checksums, I think.

[QuikSanz]

@Matt_H,

I need to archive all my old floppies. Where can I find that program "TSGUI"?

[Matt_H]

@ QuickSanz

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

[scuzzb494]

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...

Here is a list of my disks.. Note that there was the FCSystem_1.3 and FCSystem_2.0 disks. If you want to post your file sizes I can check with the disks I have.

[ Actual Disks ]
12700: Final Copy II Softwood FCProgram_II 1991-92 [ boxed ]
12701: Final Copy II Softwood FCSystem_2.0 1991-92 [ boxed ]
12702: Final Copy II Softwood FCSystem_1.3 1991-92 [ boxed ]
12703: Final Copy II Softwood FCMoreFonts 1991-92 [ boxed ]
12704: Final Copy II Softwood FCThesaurus 1991-92 [ boxed ]
12705: Final Copy II Softwood FCSpeller 1991-92 [ boxed ]

I have like over 13000 floppy disks and have most backed up on the A4000d. I still tend to use the floppies though as its easier to simply pull out the disks. Softwood programs are very stable and I haven't really had any issues.

I have other disks of the Final Copy Program. Also I have used ADFBlitzer a lot and never had any issues.

Just checked my full listing and this is all I have ...

1549: Final Copy II Rel 2 Program II [ Upgrade ]
1550: Final Copy II FC System 2.0 [ Upgrade ]

4457: Final Copy II Kickstart 1.3 [ copy ]
4458: Final Copy II Program [ copy ]
4459: Final Copy II Fonts [ copy ]
4459: Final Copy II Kickstart 2.04 [ copy ]

7902: Final Copy II Program Disk [ copy ]
7903: Final Copy II Speller Disk [ copy ]
7904: Final Copy II Thesaurus Disk [ copy ]
7905: Final Copy II More Fonts Disk [ copy ]
****: Final Copy System 2.0 disk [ copy ]

8171: U155b Final Copy II Thesaurus [ copy ]
8172: U193 Final Copy II Program Disk [ copy ]

12700: Final Copy II Softwood FCProgram_II 1991-92 [ boxed ]
12701: Final Copy II Softwood FCSystem_2.0 1991-92 [ boxed ]
12702: Final Copy II Softwood FCSystem_1.3 1991-92 [ boxed ]
12703: Final Copy II Softwood FCMoreFonts 1991-92 [ boxed ]
12704: Final Copy II Softwood FCThesaurus 1991-92 [ boxed ]
12705: Final Copy II Softwood FCSpeller 1991-92 [ boxed ]

12949: Final Copy FCThesaurus [ copy ]
12950: Final Copy FCSpeller [ copy ]

[Thomas]

To be honest I don't see what TSGUI could do better than ADF-Blitzer when creating an ADF. I assume that both programs use trackdisk.device to read from floppy and dos.library to write to a file. There is no error detection involved apart from that of the two mentioned components.

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.

Another point could be hardware and RAM integrety. AFAIK ADF-Blitzer loads the entire image into RAM and then writes it to a file at once. TSGUI reads and writes track by track. So if your RAM is not ok, it might damage the image in memory before it is written to disk. The risk that this happens is surely higher if more RAM is used and the data is kept in RAM for a longer time, i.e. for ADF-Blitzer the risk is higher than for TSGUI.

[guest11527]

strange that OS didn't complain. OFS should have some checksums, I think.

Unfortunately, the Tripos hunk format does not offer anything like that. If the length and hunk identifiers are consistent, the Os will load whatever junk it finds in the hunks. Even worse, with a "crafted" binary file you should be able to even overwrite unrelated memory.

[guest11527]

To be honest I don't see what TSGUI could do better than ADF-Blitzer when creating an ADF.

I wonder why I need a GUI for that in first place.

Code: [Select]

copy DEV:df0 to image.adf
works, and will even report errors.

[Rotzloeffel]

Will this work without installing a special DEV-Handler ?

[wawrzon]

Unfortunately, the Tripos hunk format does not offer anything like that. If the length and hunk identifiers are consistent, the Os will load whatever junk it finds in the hunks. Even worse, with a "crafted" binary file you should be able to even overwrite unrelated memory.

does elf format offer any advantage over hunk? i mean, since for instance aros delivers support for both binary formats on m68k, should elf be preferred?

[scuzzb494]

To be honest I don't see what TSGUI could do better than ADF-Blitzer when creating an ADF. I assume that both programs use trackdisk.device to read from floppy and dos.library to write to a file. There is no error detection involved apart from that of the two mentioned components.

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.

Another point could be hardware and RAM integrety. AFAIK ADF-Blitzer loads the entire image into RAM and then writes it to a file at once. TSGUI reads and writes track by track. So if your RAM is not ok, it might damage the image in memory before it is written to disk. The risk that this happens is surely higher if more RAM is used and the data is kept in RAM for a longer time, i.e. for ADF-Blitzer the risk is higher than for TSGUI.

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.

I tend to still use floppies over ADFs. I use ADFs only as a back-up. Most disks that I use on the software front can be copied so I keep working copies of disks and use those and have all my important disks stacked in diskboxes.

In respect of using ADFBlitzer the software is best for making a backup of a disk that is not recognised by the computer as readable through the Workbench. ie a self booting disk as used in games and demos. Not sure if your system works in those situations. Those are the most difficult disks to get a handle on as you cannot interogate them. Like I say I have become pretty good at listening for the 40 seconds to lapse for the read process and then I will test the disk image anyway on my Amiga 500 generally as its likely to be a demo or game disk. These disks the 4000 can't play anyway as they were designed for the 500/2000.

By the way if your disk is bust, its bust, whether its a copy or an image. And the created disk will either have to be replaced, repaired or junked anyway so its more a case of when you find out. I rebuild broken and busted disks to new images from all the various disks I have. There isn't much I haven't got.

[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.

[scuzzb494]

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!



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.

I don't have any hangups using ADFBlitzer. It serves me well, but then I am as likely to be using DMS and LHA anyway on a daily basis. The times I have needed the software to make a disk for me it has worked without issue. The trick is to have software installed and running and then backup the hard drive. I do this to ZIP disks... and amazingly since using ZIP since 96 I have never had a ZIP fail. But then I don't get anything like the issues some have with disks. Even yesterday I was on the C64 with ten 5.25" disks and they all worked a charm. So much so I never tend to ever think floppies are going to fail.

But I still keep a second copy of most stuff and copies on hard drives scattered around and on ZIP. ADF is really only useful to me for demo disks to play on the 500, like I said. I still think ADFBlitzer warrants being left out on the workbench. Great bit of software.

I recently catalogued 13000 disks and sitting at the 500 and 1200 inserting disk after disk I rarely ever got a problem. In truth its more about busted floppy drives than disks. Keep them clean, dust free etc and you will get a lifetime of trouble free use out of them. In fact if you have a problem disk first thing to do is try another disk drive. Plus if you place in DOpus and find a file not copying over just repeat the process, and even take out the disk and tap it on the table and try again. I very often get a file to travel over in the end. Checking file structures on disks is actually quite important and I wouldn't rely on Blitz to do that. Never have, there is zero information on the copy process. Not even when complete.

PS As an aside here are the 5.25" floppies I was talking about.

http://www.scuzzscink.com/amiga/scuzzblog_august17/scuzzblogdaugust17_2801.htm

[kolla]

Will this work without installing a special DEV-Handler ?

Of course not

http://aminet.net/package/util/sys/Dev-Handler

It is darn useful, though a little "dangerous"