1

It is a large disk and it seems all files but a few are readable. For the few files, reading fails at the same point. Something like position 1.5GB of a 5GB file. The SMART data does show unrelocatable, so I guess it is a physical error. But I am pretty sure that not the entire non-readable 3.5GB are on bad sectors. Probably, the NTFS file system stops at the first bad sector it encountered.

So, I want to recover all the readable part of the files (non-readable parts could be filled with 0x00). It seems that chkdsk /f /r would do it, but it takes tens of hours because it tries to scan the entire disk. I already know the names of the few files for which reading fails. Can't I do /r for only specified files, or at least specified directory?

/r Locates bad sectors and recovers readable information. The disk must be locked. /r includes the functionality of /f, with the additional analysis of physical disk errors.

3
  • 1
    I'd do a built-in diagnostic on the drive, if it fails I'd use ddrescue to recover the data since you can't fix the drive at that point & the more you access the drive the more likely it will fail further
    – gregg
    May 23, 2022 at 2:40
  • 1
    @gregg By build-in diagnostic can I assume you mean a S.M.A.R.T test. ? (It may not be clear to the OP). Absolutely agree with you.
    – davidgo
    May 23, 2022 at 3:21
  • Or use another cloning tool running from a bootable drive, such as Macrium Reflect's rescue USB drive. Operate on the clone, rather than further damaging the HDD. May 23, 2022 at 3:50

1 Answer 1

1

It is a large disk and it seems all files but a few are readable. For the few files, reading fails at the same point. Something like position 1.5GB of a 5GB file. The SMART data does show unrelocatable, so I guess it is a physical error.

Please provide the relevant line out of your SMART report created with smartmontools. I never read the term "unrelocatable" in SMART reports.

Solution 1

So, I want to recover all the readable part of the files (non-readable parts could be filled with 0x00). It seems that chkdsk /f /r would do it,

I doubt that chkdsk will produce files in your desired output format. The solution under linux could be to apply the ddrescue command individually to each broken file:

ddrescue brokenfile recoveredfile mapfile

where

  • ddrescue is the command
  • brokenfile is the full path to your brokenfile
  • recoveredfile the full path to your recoveredfile, this should not reside on your device with broken files
  • mapfile is logfile describing the current state of recovery and after finish will also denote the areas of the file that have been recovered

https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html states

If the output file is a regular file created by ddrescue, the areas marked as bad-sector will contain zeros. If it is a device or a previously existing file, the areas marked as bad-sector will still contain the data previously present there.

Solution 2 (incomplete, only a possible hint)

There is a new parameter in chkdsk called "spotfix". I did not find any satisfying explanation of it. Running only legacy operating systems I can't run chkdsk /? to read the built-in help text. This might be of interest to you.

2
  • Well, I remembered the term incorrectly; it was "uncorrectable". Anyway, it turned out that you can't cancel chkdsk /r. The ETA was not accurate and it was finished. The result was that it found bad sectors and "Windows replaced bad clusters in file". Those files were all those I had known, except one new file whose file number was close. After this, reading did not fail at that location, and I could copy the entire files to a new drive. I had run spotfix before, but it did not find anything. May 23, 2022 at 10:25
  • See superuser.com/questions/1027733/in-chkdsk-what-is-spot-fixing for a better description of /spotfix.
    – riQQ
    Jul 6, 2022 at 9:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .