Then I took the copy of the image under Windows. This way I didn’t care what the ext2ifs driver wanted to do. But this time it didn’t mangle the partition (probably because this ext2 partition actually has a legal physical formatting!).

Finally I can run NTFS tools on the broken disk, but I need to mount the (broken) NTFS image first. There is a free tool, FileDisk by Bo Branten, to do this. Unfortunately, it gives a drive letter to the whole disk, instead of to the partitions. This is nearly impossible to work with because (1) there are 63 sectors of MBR, partition table, and filler at the front of the disk, and (2) there is the Dell diagnostic partition. And FileDisk doesn’t virtualize a physical disk device, which would be the more correct metaphor.

A way around this is to use VMWare, and virtualize the disk image as a disk. But no, that’s too much trouble… although, after this incident, I’m really considering putting a VMWare image with Windows preinstalled onto a DVD or something — that would be the complement to Knoppix.

A somewhat more advanced tool called Mount Image Pro (MIP) exists that does what I want. It isn’t free (*), but who cares when there is a one-month trial? (For the record, I’m not entirely happy with this thing, either. It works, but almost every other time it fails to load the system driver and requires a reboot and retry.)

With MIP, the NTFS partition comes up and is mounted under K:, but it is completely broken as expected. The file system cannot be read normally by Windows, nor would the diagnostic tool NFI (part of the OEM Support Tools) work on it. NFI relates what files a sector contains and what sectors a file resides in.

The next step is then to run chkdsk:

> chkdsk /v K:

Very specific errors relating to the file table are immediately detected and chkdsk says it cannot continue in the (default) read-only mode.

So let’s try

> chkdsk /v /r K:

Same complaint by chkdsk. What? It turns out MIP (at least the GUI) only mounts images in read-only mode, but it doesn’t specify this anywhere! Nor does it give an indication of how to get around this. Wow great.

After poking around, I noticed there is a command-line interface to MIP, too, and it is there that you can specify mounting in “read-write” mode, instead of “write-block” mode. (I would also call “write-block” mode “read-only” mode, but that’s just me, so what do I know!) Moving on:

> mip mount rescue.image /rw /p:2 /l:K

Finally, the second partition in the disk image is mounted on the drive letter K: (hence the last two parameters). Unfortunately, MIP screws up again and says there is only “1″ partition, and the drive letter K is associated with the first, Dell diagnostic, partition… even though it clearly displays two partitions and that the drive letter K is in reality associated with the second partition. No matter, it still works, so I’ll leave the MIP people unflogged. But they should still go home and fix these.

Trying chkdsk again and it slaves away through a 5-step process, dumping output on all the files and directories on which it detected problems. The disk image is broken enough that chkdsk had to kill most of the NTFS file permission. After about 2 or 3 hours, K: is miraculously readable again in Windows, with the basic directory structure at first glance intact. Very glaring, however, was that K:\windows isn’t there. There is a new K:\found.000 folder with all the directory trees that lost their names (but otherwise fairly intact) re-rooted there. There were 30+ such re-rooted directories, and it was trivial to find the one that should be K:\windows.

Running through the directories on the disk image that had been combed over by chkdsk, everything was readable and accessible. I’m more worried about the data parts that got zero-filled by ddrescue, which makes for a much more insidious type of data corruption. On the other hand, I am comforted by the high percentage of data that must not be zero-filled based on the percentage of raw recovered bits recovered by ddrescue. Also, anything that chkdsk had a problem with (in the file table) must have been due to zero-filling. Thus, the more problems chkdsk found, the less problems remain in the data portion, so statistically I am satisfied. With NFI, the extent of the damage at the file level can be ascertained precisely, but for all practical purposes, the recovery is near total. Certainly, all the files that I care about (defined as those not “easily” regenerated), which was maybe 20GB of the 40GB, are recovered, including really small text files to fairly large (hundreds of MB) NTFS compressed files.