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.

Damn Vegetables
  • 3,622
  • 16
  • 46
  • 78
  • 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 '22 at 02: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 '22 at 03: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. – DrMoishe Pippik May 23 '22 at 03:50

1 Answers1

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.

r2d3
  • 3,298
  • 1
  • 8
  • 24
  • 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. – Damn Vegetables May 23 '22 at 10:25
  • See https://superuser.com/questions/1027733/in-chkdsk-what-is-spot-fixing for a better description of `/spotfix`. – riQQ Jul 06 '22 at 09:20