TSGui bad sector checking

[prowler]

Can anyone tell me for sure what triggers the TSGui error messages "Bad sector checksum" and "No sector header", please.

The reason I ask is that I have an AmigaDOS formatted floppy disk which, when inserted in floppy drive of an Amiga running Workbench 3.1, triggers a requester reporting that an error validating the disk has been caused by a bad header type in block 881.

Cancel this, and another requester warns of a checksum error on disk block 946.

Cancel this, and the disk icon apears on the desktop.

Double-clicking the disk icon produces a swatch of requesters warning of a further 47 disk blocks with checksum errors before a single zero byte file icon appears in the window, although the title bar reports 100% FULL, 512 B FREE.

Using the List command from the Shell reveals a single file with the same name of 2048 bytes length using 6 blocks.

There are many checksum errors reported by Workbench for this disk, which give rise to the conflicting information reported about the disk content, and yet, despite this, TSGui is able to produce an ADF copy of the disk without reporting a single error!

Does TSGui actually check that the data checksum is in agreement with that which appears in the header? Or is the "Bad sector checksum" message simply a consequence of an error reading the disk block data, and the "No sector header" message that of an error reading the corresponding header?

I have not tried mounting the resulting disk image in WinUAE yet, but I suspect that it's behaviour will be similar to that of the disk in a real Amiga.

[Toni Wilen]

The difference is between physical (disk) errors and logical (filesystem) errors.

Disk imagers won't (and must not, or you would not be able to copy any disk correctly with fake filesystem structure..) care about filesystem errors.

Your disk has perfectly fine Amiga low level format (image copies fine) but is full of filesystem errors (saddam or similar virus damaged?)

[prowler]

Thanks for your explanation, Toni.

This was originally an Amiga Format 117a coverdisk, and was recently sent to me by Titler for converting to ADF for contribution to AMR.

However, the disk has been overwritten and now appears to be a "ProText Data Disc".

I have some experience of recovering data from floppy disks with physical errors, but, as yet, no experience whatsoever of those with filesystem errors.

I have a feeling that this disk is destined to change that...

[thomas]

I have some experience of recovering data from floppy disks with physical errors, but, as yet, no experience whatsoever of those with filesystem errors.

The procedure is always the same: first use a track-copy program like X-Copy or the like to copy the data to a floppy without physical errors, then run a program like DiskSalv which can recover files from disks with logical errors.

The second step is always needed, even if the disk does not have physical errors. The error messages are similar, either. A physical error (unreadable block) always leads to a logical error (missing or corrupted data), too.

[prowler]

Thanks, Thomas!

I guess I shouldn't have much trouble applying the usual tricks, then.

Now that I know the disk has been overwritten, I'm not trying to reconstruct the disk image any more. However, I would like to recover some or all of the files it now contains, just to see if that will help Titler remember how the disk got overwritten. He does remember using ProText on his Amiga as his word processor throughout his student days, so that's most likely when it happened.

I think I'll see what DiskSalv can pull off the disk.

[prowler]

Using DiskSalv, and working with a copy of the disk obtained from the image which TSGui produced from the original, I have been able to recover almost everything which was on the disk before it was overwritten!

First, I had to let DiskSalv validate the disk, for it wouldn't let me do anything else without that step. Then, I searched for deleted files, but there weren't any.

Next, I carried out a salvage operation to a folder on my hard drive, and recovered the boot sector, volume information and all the files and directory structure of the disk with no reported errors.

Naturally, this information reflected the change in volume name from "ADF117a" to "Protext Data Disc", modified the disk creation date (again) and included an extra file which had been added to the disk by the owner, but it was an excellent start.

Finally, I let DiskSalv repair the disk, which saved the date and time stamps of all the directories, but killed one of the files, due to data errors.

Unfortunately, the damaged file is not only the largest on the disk (approx. 700kB), but it's also a compressed (lzx) archive.

Therefore it is likely that the salvaged version of this file is damaged with at least as many errors as there were checksum errors on the original disk, and the tight compression of lzx archives will make it difficult to repair.

However, there is some good news: I have downloaded a copy of AFCD 33 from the EAB File Server, and that includes the content of the AF117 coverdisks as uncompressed files. I can therefore attempt to recreate the compressed archive (or maybe just the damaged portions of it) by trial and error, looking at the damaged archive with a binary file editor to discover which files to compress and in which order.

Thanks, Toni and Thomas, for your help, which got me started.

PS. I think that the most likely cause of the damage to the filesystem of this disk is that it was removed from the disk drive while it was being written to. I don't expect to find that that the boot sector is infected with a virus, but that's something else I will check with the binary file editor.

[prowler]

Today, after a lot of work, I finally have a reconstructed, working disk from the AF117a disk with filesystem errors caused by partly-overwriting it.

To do this, I used my Amiga 1200 and WinUAE running Workbench 3.1, the Amiga tools TSGui, DiskMon Tools, LZX 1.21 and 1.20 Registered versions, DiskSalv and TrackEd, Cygnus Hex Editor for Windows and ChkSum, CopyDate and DirDate command line utilities for DOS, together with replacement files from an AF103b disk image from AMR and Fiasco 2.22 main and English docs archives from Aminet.

Thanks to both Toni Wilen and Thomas Rapp for their suggestions and help with this, which put me on the right path!

[Supamax]

WOW, what a great recovery effort!!

[AmigaFriend]

Originally Posted by prowler

To do this, I used my Amiga 1200 and WinUAE ruinning Workbench 3.1

I hope you have backups of your disks. But maybe you can always recover them! Great effort and skills mate!

[prowler]

Originally Posted by xpect

Thanks for spotting the typo, mate. I was getting rather tired by then.