Get list of files affected by bad sectors

Question

Cloned a disk with pending sectors to a new drive with Clonezilla using -rescue, then plugged the freshly cloned disk into a working system as a USB drive (I have a USB-to-SATA dock) and ran chkdsk.

In read-only mode, chkdsk found no errors. With /B, chkdsk cleaned up some instance tags, unused index entries, and corrected free space marked as allocated in both the MFT and volume bitmap.

It's this last bit that has me worried. Clonezilla reported that several sectors could not be read and that it had "lost data". I assume those sectors became the free space marked as allocated, which chkdsk cleaned up. But I can't find anywhere what files were allegedly using the allocated space, so I don't know what to restore from online backup.

Is there a tool that can tell me to which files the bad sectors had been allocated? Perhaps if I run it read-only on the original drive instead?

Answer 1

This question was asked several months ago, I hope you have found a suitable answer in the meantime. Still, here's one that I used with great success recently on a failing 1TB HDD that someone handed out to me in the hope that I could “make him talk”, and recover as much data as possible without paying an arm and a leg for it ! :^p It turns out that I managed to recover a very high percentage of his personal files, on a hard disk drive affected by the infamous click-of-death : only about 125 were corrupted by irrecoverable sectors, which I identified with this method, and since most of those files were duplicated once or more, I could then restore or repair most of them (using DoubleKiller Pro in size-only mode to detect the duplicates – in some instances 2 or 3 normally identical files located in different places had corrupted parts which were different and complimentary so I could regenerate the original using WinHex, that's kinda advanced stuff for a mere “amateur”), so only about 20 files remain partially or totally corrupted. (And I asked only 50€ to do this ! O_o Oh well, it was instructive at least...)

– Recover the original storage unit using ddrescue, with a logfile / mapfile.

ddrescue [options] [input drive or partition] [image file or volume] [logfile]

– Once the recovery is considered finished, as it is almost certainly a NTFS partition, run ddru_ntfsfindbad, included in ddrutility, using the output image or volume and the logfile / mapfile as input. That tool will analyze the logfile / mapfile (now it's called "mapfile", used to be "logfile"), which indicates what areas have not been recovered, and compare it with the informations found in the MFT. It proceeds very quicky (it took 2 minutes to analyze a 919GB partition), and produces a list of the affected files, with the exact size of the error(s). Of course it requires that the MFT has been fully recovered to work properly (it is generally located at the begining of the volume, in my case the first 165GB or so were recovered without errors so it gave reliable results).

ddru_ntfsfindbad [-V] -i [partition offset] [ddrescue output] [ddrescue mapfile] 

Excerpt of the list I obtained (edited with TEDNotepad) :

name=./Users/titi/Desktop/Documents/Films/Clones.avi    errors=0006 errorsize=163549184 FILE    inode=4942
name=./Users/titi/Desktop/Documents/Films/Cloud Chasers Les Traqueurs de Tempêtes.avi   errors=0005 errorsize=160069632 FILE    inode=91564
name=./Users/titi/Desktop/Documents/Films/Contagion.avi errors=0003 errorsize=173576192 FILE    inode=3410
name=./Users/titi/Desktop/Documents/Films/Fast and Furious 5.avi    errors=0003 errorsize=163557376 FILE    inode=5076
name=./Users/titi/Desktop/Documents/Films/Green Lantern.avi errors=0003 errorsize=163553280 FILE    inode=13740
name=./Users/titi/Desktop/Documents/Films/Numéro 4.avi  errors=0003 errorsize=163553280 FILE    inode=5252
name=./Users/titi/Desktop/Documents/mes chiens/MapsAppList.targetsize-48.png    errors=0001 errorsize=000551    FILE    inode=301935
name=./Users/titi/Desktop/Documents/mes escargots/Recette d'Escargots à la catalane_files/430(2)    errors=0001 errorsize=035793    FILE    inode=84109
name=./Users/titi/Desktop/Documents/mes escargots/Recette d'Escargots à la catalane_files/430(3)    errors=0002 errorsize=032768    FILE    inode=84118
name=./Users/titi/Desktop/Documents/mes escargots/Recette d'Escargots à la catalane_files/430(5)    errors=0001 errorsize=036864    FILE    inode=84745

Answer 2

Another possible way of doing it, if Clonezilla (or any other imaging software) gave you a complete list of the bad sectors' LBAs : use Microsoft's nfi.exe tool. It's a very small command line tool which can parse the MFT and either provide a list of the sectors occupied by a given file (if you enter a file pathname), or find the file corresponding to a given sector.

---

Yet another possibility : some defragmenters display the files associated with the blocks that you hover over with the mouse pointer. (It's less accurate but more convenient.)

---

Again another possibility : R-Studio includes an hexadecimal analyzer (and rudimentary editor). For each file it detects and displays in a recovery tree, you can right-click to open the hexadecimal analyzer, then in the “Data interpreter corner”, click on the “Sectors” tab, and voilà, you get a list of the occupied sectors. To get only the number of the first sector, click on the “Properties” tab and read the last line.

Another advanced trick with R-Studio : in the recovery tree tab for a given partition (can be a clone of the original, can also be an image file), click on “File” then “Show files in HexEditor” : this will create an entire hexadecimal presentation of the volume with all the associated file names (can take some time for a large volume), which you can then use to find which files are associated to a given sector. To do this, return to the “Device view” general tab (the one which is displayed when you open R-Studio, which lists the available volumes), right-click on the volume that you are trying to recover from (the entire volume, not the individual partitions), and then click on “View/Edit” to display the hexadecimal presentation ; here you can enter a sector number or offset value in the blank field in the middle of the upper tool-bar. It has a small bug or inconvenience though : in my experience (with R-Studio 8.0), to display the content of a given file you have to enter the logical sector number relative to the partition where it's located (the number displayed at the last line in the “Properties” tab in the individual hexadecimal view of a selected file), but to get the name of the file (or sometimes files, when there are hard links, or when a file has been identified both within the file system and as a raw file appearing in “Extra found files”) associated with a given sector, you have to enter the absolute sector number, relative to the whole volume, so you have to add the offset of the partition in sectors. For instance, I analyzed a 3TB HDD, with a single partition begining at offset 135266304 (129MB), so, in order to display the name of the file(s) associated with logical sector 1000000 for instance, I had to add 135266304 / 512 = 264192, and enter a value of 1264192 (but then the content displayed didn't match, the actual content of the file would be displayed at sector 1000000 indeed).

---

WinHex can also analyze a NTFS partition (possibly other file systems too, never tried but it's supposed to), or an image of an entire volume (provided that you open it by selecting its correct type in the “Open” menu – generally “All types of images” works well), and for any given location it will display the name of the associated file, or indicate if it's registered as free space.

---

I don't know if it's possible to get a list of the bad sectors once they have been reallocated, though. At that point, they are presented by the HDD to the system “transparently” (or rather “obscurely” should we say) just as if they were the original sectors in the sequential order, and the original sectors are gone forever, from what I could gather. (Someone could make a song with that shit, and sadly, in 2017 it could become a hit!)