Help me examine my FAT.

July 20, 2008 8:32 PM

How can I figure out what file a particular FAT32 sector belongs to?

I recently used ddrescue to recover data from an old 30 GB drive that had gone bad. ddrescue took about 24 hours to run, but when it finished I had a 99.99+% good copy, with only about 70 errors. The partition information is OK, so I can read the new drive with no problem. So far, so good.

Now I'd like to figure out which files the unreadable sectors belong to, so I know if any important files were compromised files. I have the ddrescue logfile, which lists the drive contents as blocks of readable/unreadable sectors. How can I use this output to figure out which files were not recovered completely?

I've seen this post on the ddrescue mailing list (linked to by flabdablet in a previous question about data recovery), but my drive is FAT32, and MSFT's nfi.exe doesn't work for non-NTFS drives. I found another post on the ddrescue mailing list by the same author, in which he links to a Perl program of his that looks up FAT32 filenames based on input from the ddrescue logfile. Exactly what I need, right? However, the program is listed as "under construction" in his post, and it doesn't work for me with sectors numbered above about 10,000,000. Unfortunately all but 8 or 9 of my unreadable sectors are above that threshold. I've banged my head against its 1500 lines of code for the last week or so trying to find the reason it fails and succeeded only in making my head hurt. (I emailed the author about it last weekend and have gotten no response.)

I did the initial ddrescue-ing on an ancient Pentium II running Debian Sarge, but I also have a more modern machine running Win XP. Any suggestions?

posted by harkin banks to computers & internet (3 comments total)

NTFS uses a b-tree filesystem that is much more robust. I don't think you can do what you want in FAT32 since each sector only has a pointer to the next one in a chain. We wouldn't need expensive data recovery if orphaned clusters had this property, unfortunately. Caveat: I haven't paid attention to a lot of this for a few years, so my contribution is just based on standards.
posted by rhizome at 10:52 PM on July 20, 2008

I don't see any reason you can't do this for FAT32. Yes, you'd have to track the allocation chain backwards, which is a pain. But no more more painful than figuring out who owns an indirect allocation bock on BSDFFS, for example.
posted by hattifattener at 12:03 AM on July 21, 2008

If it were me, I'd just grab a copy of a hex disk editor like WinHex, and have at it, maybe using the ddrescue log as a guide. The WinHex data analysis system is template driven, and is pretty intuitive, and can quickly spot problems with FAT corruption, including files with bad sectors. Unless you object to paying for WinHex, or are committed to working the problem backwards from a bad sector list from a ddrescue log as some kind of programming project, or technical exercise, I think you'll find that using FAT, top down, is a lot easier.
posted by paulsc at 12:40 AM on July 21, 2008