Fixing fatal FAT32 problem

I’m rebuilding an old-ish PC that’s on its way from one family member to another. The PC is one of those that has the OS in a restore partition on the hard disk, rather than shipping with a CD. OK, no problem to re-install from the restore partition after performing a NTFS reformat on the main data partition. The problem I had was that the D: partition had got some corrupted files – not the OS restore files, fortunately (then I would be been dead in the water), but the previous owner had managed to add some photos to D:, and these files were corrupted. Why a system restore partition is not read-only I have no idea.

OK, so disk problem. Not normally an issue, just run the ‘error checking’ tool from the tools tab on the disk properties menu, then reboot. The disk check runs during the boot phase, so that the OS can get low-level access to the drive. Except that, in this case, the disk check would get about 90% complete, then some low-level fault in the file system would cause the machine to reboot. Without marking the disk as clean. Indeed, the file system wasn’t clean as the dead files were still there. This would happen on every boot, unless I manually ask the disk checker to skip the check, which only defers it to next boot cycle. I didn’t want to hand over the machine in this state.

Fortunately, there was a solution. I downloaded the latest version of Knoppix Linux, and burnt a boot CD. Knoppix is a “live” linux - it runs from a CD without installing any files on the hard drive. Once in Knoppix, I launched a root shell and ran the FAT32 flavour of fsck on the dodgy drive, which appeared as /dev/hda1 on my system:

$ dosfsck -a -t -w -V /dev/hda1

It took about an hour in total, but managed to repair the broken FAT32 file system on what Windows sees as the D: drive. Thereafter, Windows still needed to run the disk checker once during boot, but found no errors and marked the drive clean. Subsequent boots were fine.

 newer · index · older