Bad Diskette Data Recovery
Here's a fairly standard way of recovering data from diskettes that have bad sectors:
1: Protect the diskette
Windows 9x will write to every diskette it sees, even if you don't do so yourself. Specifically, it writes a tracking ID to the boot record of the diskette, so it can determine whether a different diskette is in the drive. Should the drive be faulty or misaligned, or the diskette be frail, this process could corrupt the first track and render the diskette unreadable. I don't know whether NT (including Windows 2000 and XP) behave the same way as Win9x in this regard.
So the first thing to do is to open the write-protect tab in order to prevent further damage! As a general rule, I treat the write-protect tab much as I would the safety catch on a gun; it stays "safe" unless I'm planning on writing to it.
2: Get out of Windows
Windows is generally a bad place to attempt anything that involves potential hardware error conditions. You'd think after two decades of writing Disk Operating Systems, Microsoft would be able to handle disk errors gracefully, but Win9x tends to lose its marbles in cases where DOS would have thrown up an ARF message and carried on truckin'.
What comes next requires direct (raw) disk access anyway, which modern Windows precludes - so get thee to DOS mode!
3: Prepare a target diskette
Format an error-free blank diskette, then fill this diskette with a single large file. The easiest way to do that is to start an archive to the diskette that would span multiple diskettes, then abort this after the diskette is filled.
If you anticipate holes in the data cluster area of the original diskette, then you can do yourself a favor by filling the data cluster area of the target diskette with a repeated unique string, e.g. "!!_BAD_SECTOR_!!" - i.e. something that a Find won't find anywhere under normal circumstances, and that will align nicely in 512 bytes (e.g. this 16-byte example).
4: Peel off the contents of original diskette
I use "Norton" DiskEdit for this, but if you have a raw diskette copying utility that will do the job without having hissy fits about what it can't read, then use that instead. In fact, if that utility is smart enough to copy directly to another diskette while leaving any unreadable sectors untouched on the target, then you can do the next step at the same time.
I usually PgDn through the raw pysical sectors on the sick diskette until I get a disk error. I ballpoint that CHS address, then select all physical sectors up to but excluding that sector. Then I write these sectors to a file (e.g. A1.SEC) somewhere on the hard drive (e.g. C:\BAD-DISK). Then I repeat this process, noting down all bad sector addresses and saving what is good in successively-numbered files (e.g. A2.SEC, A3.SEC, A4.SEC etc.)
5: Splat the contents onto the target diskette
Taking care to do this in the right order, and to ensure each slab of saved sectors starts at the correct CHS (raw physical disk) address, I then load each of the saved files into DiskEdit and write these to the target diskette as raw sectors.
Don't confuse logical sector numbering with physical sector addressing, which is often shown in CHS form.
6: Copy off and test the files
You may still have file system issues to contend with; there may be wads of garbage in your files, and if the files on the original diskette were fragmented or oddly ordered and were chained via lost sectors in the FAT, then you may have incorrect data clusters in the files. But at least you aren't fighting two battles at the same time; logical errors plus a collapsing disk surface.
7: Resolve FAT errors
Where there were missing sectors in the FAT, but the files were unfragmented and saved in a first-to-last order with no deletions, you should find the data clusters chained into the files will be correct - because you effectively created a "flat-FAT" at step (3), and where step (5) left this FAT showing through, the chaining would have been appropriate.
However, if there are chaining errors, it is still possible to fix these, even if the corresponding sectors in both copies of the FAT are both corrupted. Any non-zero or non-"special" cluster address should occur only once in a FAT, so you can narrow down the search for loose data clusters by looking for addresses that appear both in the "flat-FAT" show-through and the real FAT as successfully lifted off the original diskette. Resolve duplicates (which are crosslinks) in favor of the original FAT, i.e. chain out what is in the "flat-FAT" so that no duplicates remain - using addresses that don't appear anywhere in the original FAT.
Some cluster addresses won't appear in the FAT because they are the first clusters of a file or subdirectory, and it's easy to look those up by looking at the root and other directories and ballpointing all the start cluster addresses there. Any addresses not accounted for in the original FAT or directory entries may be assumed to constitute the cluster chains held within the bad sectors lost from the original FAT.
8: Spot and fix missing data sectors
You can load the salvaged files into an ASCII viewer, and look for the unique string you used in step (3). You should find 512-byte wads of these wherever a data sector could not be read off the original diskette, leaving the filled data cluster contents from step (3) in place.
If there are multiple similar copies of the same file on the diskette (e.g. BLAH.DOC and BLAH.BAK), then you can lift the corresponding sector from the heathier file and paste it into the hole in the damaged one. The chances of successfully fixing binary files (such as spreadsheets) via such shenannigans are small, but at least with a word processor document file, you can load it into Edit and strip out binary stuff to leave editable text.
(C) Chris Quirke, all rights reserved - November 2002
Back to index