cgsecurity.org

One detail I forgot to mention is the number of error messages in the log (stop by a segmentation fault):

The first log was this...
Using locale 'en_US.UTF-8'.


Sun Oct 18 20:37:23 2020
Command line: TestDisk /debug /log /dev/sdb

TestDisk 7.0, Data Recovery Utility, April 2015
Christophe ...

A NTFS file system has no FAT.
yes, I must have been thinking of another hard drive with FAT32 partition.

As for your questions, I don't know why your drive is misbehaving. It is little surprising that you are refraining from formating or zeroing an empty partition.
Probably I messed up my ...

The cloning was done in the same hard drive" contradicts the idea of using ddrescue.
I get your point, but I'm assuming the hard drive is healthy, just the FAT (that's my guess) of one partition is damaged. The damage is logical, not physical (according to its SMART report).

47 Petabyte or 47 ...

I did run ntfsresize getting a lot of error message about clusters:

# ntfsresize --info --force --verbose /dev/sdc8
.
.
.
Cluster accounting failed at 133119996 (0x7ef3ffc): extra cluster in $Bitmap
Cluster accounting failed at 133119997 (0x7ef3ffd): extra cluster in $Bitmap
Cluster accounting ...

I don't know what the backslash are standing for above.
I like to put every command option in a separate line for easy reading, that's all.

"The cloning was done in the same hard drive" contradicts the content of your ddrescue command.
why is that?

It appears strange that you are trying to ...

But I would prefer a log file from smartmontools over a picture from CrystaldiskInfo.

I didn't deliver a smartclt report in the post because I hadn't been able to get one from the hard drive through a JMicron SATA bridge (Samsung Story Station). Yesterday I finally found the solution in a forum ...

TestDisk is unable to undelete files from a faulty NTFS partition on a healthy hard drive (according to CrystalDiskInfo there are no bad sectors in it). But chkdsk has been unable to fix the error. What I need now is to understand what this TestDisk error message means to find the best solution ...

If few files are recovered it could mean that the block size was not selected properly. The block size detected during the initial test can be wrong, in which case Photorec's scan won't find file signatures at cluster boundaries, and will only detect false positives. Try selecting a smaller block ...

@cgrenier: I started a new PhotoRec session with all options in its default values (force brute deactivated), and PhotoRec recovered thousands and thousands of files, so your advice worked like a charm

That's a very interesting clarification that should be included in the manual, or even better: on the footer of the PhotoRec configuration screen.

The hard disk is not encrypted (none of my disks are).

Maybe I'll give it another try with the brute force feature deactivated to see what happens.