How do I find if there are files at a specific bad sector?

Solution 1:

– You'll find nfi.exe here :
http://www.jumpjet.info/Application-Software/Windows/win2k.htm
Download “oem3sr2.zip”, it's in there. The command is :

nfi X: [sector number]
(Replace "X:" with the relevant drive letter.)

You can also get a complete listing of all files on a given partition if you don't specify a sector number :

nfi X: >"D:\nfi listing.txt"
(Replace "X:" with the relevant drive letter. Adjust the name/path of the output file.)

(The resulting text file can be huge if there are a lot of files on the analyzed partition. For the 3TB HDD I'm currently working on, it extracted a listing file of 425MB.)

– The fsutil tool which is natively present on Windows (at least Windows 7) can also provide this function, among various others. The command is :

fsutil volume querycluster X: [cluster number]
(Replace "X:" with the relevant drive letter.)

Here the input has to be in clusters, so you have to divide the sector number by the number of sectors per cluster, usually 8 for a common 4KB cluster size. The presentation of the result is more streamlined than that of nfi.exe, which can be confusing if a file has many fragments (apparently a single file can be presented as several file numbers in the MFT, and nfi displays only one of these parts, I haven't quite understood how it works yet) ; also, it can give the short name instead of the full name, thus requiring extra steps to identify that file with certainty (for instance I got “2017_0~3.MP4”, in a folder full of video files with a full name begining by “2017_0”). With fsutil you get one line giving you just the info that you need, reliably :

Cluster 0x000000001ec1ba42 utilisé par ----D \fichiers corrompus\2017_07_2122_49 - Arte - 101 - Depeche Mode.mp4::$DATA

(The cluster number is always displayed in hexadecimal format, but you can type it in decimal format ; here, I requested cluster 516012610. It's in french ’cuz I'm in France! :^p)
With both tools you have to provide the logical sector or cluster number to get the correct result, so if Clonezilla gave you a list of absolute or physical sector numbers (which is probably the case, even though I haven't tried it, since a cloning software is designed to copy everything with no regard to the partitioning scheme) you have to remove the offset of the partition. For example, with the 3TB hard drive I'm working on, there's only one partition begining at sector 264192, so if I have the absolute number of a bad sector (provided by HD Sentinel for instance – see below), let's say 4128365072, and want to know which file it belongs to, I have to type 4128365072 - 264192 = 4128100880 with nfi.exe, and 4128100880 / 8 = 516012610 with fsutil.

Other tools I know which can provide that kind of information :

– Hard Disk Sentinel (not free but it's the best software I know for hard drive health assessment purposes) provides the absolute or physical sector numbers (relative to the complete physical device rather than a given partition). When you run a surface scan, click on a given block, it will display an hexadecimal presentation of the first sector from that block, then you can go to any other sector by clicking on “Go to” (you also have to specify the absolute sector number), and if you click on the “Detect file information for sector” box, it will display which file occupies that sector, and the complete list of sectors occupied by that same file. It has a caveat, though : it will try to actually read each sector requested that way (so as to display its content), which can unnecessarily stress an already damaged area and expand it, without recovering anything as a cloning software attempts to do. (I'm having a similar issue to deal with right now ; in my situation the number of bad sectors increased while I was trying this method, even though I tried to identify the affected files by accessing sectors nearby instead of directly requesting the ones already identified as bad).

– Recuva provides the list of logical cluster numbers for each file in the “Info” tab. It doesn't do directly what you need here : it provides the list of clusters occupied by a given file, but it does not allow to find which file is on what sector. Still, this lesser known functionality of Recuva can be used in combination with the tools above : once you know which file occupies a given bad sector, it can be useful to know which sectors are also occupied by that file, to see if it is recorded sequentially or heavily fragmented for instance (in my case several affected files are heavily fragmented, so I could not practically extract them from a partial ddrescue recovery of the relevant range of sectors without the file system information, as I first intended).
Make sure to run a quick scan (default method), that's enough to parse the MFT and get the indexes of the currently allocated files, and it won't stress the hard drive by fully parsing it if the damaged areas are located further (as is the case with mine : all the bad sectors are around the 2TB mark). If a file containing bad sectors is large enough and the bad sectors aren't right at the begining, it should be harmless, but with small files or if bad sectors happen to be at the begining, just clicking on them to get the list of clusters they occupy could increase the damage as Recuva will attempt to display a preview or at least the header.

– Defraggler from Piriform (same company which develops Recuva) : when clicking on a given block on the volume's map, it will display a list of the files contained in that same block (even non-fragmented files). And when clicking on a file name in the “File list” tab (which only displays fragmented files), it will highlight all the blocks containing at least one sector belonging to that file. Unfortunately there is no numerical indication of offset / sector / cluster intervals. (I wrote them to request a few enhancements which would make this great feature more practically usable.)

– R-Studio (not free either but it's one of the best recovery softwares I've tried) can display the sectors occupied by any file in the recovery tree (even those in “Extra found files” which are not currently allocated but are carved according to their header/footer structure) by opening the hexadecimal viewer and clicking on the “Sectors” tab – but it currently provides no way of exporting that list (you can copy values one by one with CTRL+C, but not select them all ; with Recuva or HD Sentinel it's possible to copy the whole list for further investigations).
You can also identify which file is on a given sector with this method :
1) From the recovery tree, click on File => “Show files in HexEditor”.
2) Then go back to the device view tab, right click on the volume which you are examining, then “View/Edit” : this will open the HexEditor (which is more an hexadecimal viewer, by default it's in read-only mode, as it should be for data recovery purposes). Here you can type a sector number and display it as well as get the name of the file it belongs to. There's an inconsistency though : to display a sector's content you have to type its logical number, but to get the name of the file it belongs to you have to type its absolute number, adding or removing the partition offset.
Again, in the case of a failing HDD (hardware failure), this method is risky as the software will attempt to access the defective sectors.

– With ddru_ntfsfindbad, a tool from the ddr_utility tool set, you can get a list of files occupying sectors which ddrescue (a command line cloning program specifically designed to recover data from failing storage units) could not read. It works with a logfile generated by ddrescue. In this case you already cloned the failing HDD with Clonezilla, but if there are only a few bad sectors it's still possible to create a custom logfile from a template, without having to go through the cloning process all over again. It has the advantage of providing detailed informations, most notably the size of the corrupted data for each affected file. It runs on Linux though, which is another caveat, so it's not the easiest solution in your case, but it might help others who actually made a recovery using ddrescue.