ddru_findbad on exFAT

[j-sharp]

Hello everyone!

I am trying to rescue a broken sd card with exFAT using ddrescue. So far only 375 kb are left in bad sectors which could not be recovered (rescue still running since almost 1 month).

Hence, I tried to speed-up the rescue process by creating a domain mapfile by using ddru_findbad as I need to return the card to the retailer soon.

Using ddru_findbad 1.11 on Cain 8.0 live CD on the image and logfile created by ddrescue, I received the following (extract of the relevant output):

Checking /dev/loop1p1
Partition /dev/loop1P1 type exFAT is found to be none
Either you selected not to process this partition,
or fsstat could not determine the partition type.
Therefore the partition cannot be processed
The partition type may not be supported
Or the filesystem may be damaged
fdisk reports the partition ID is 59.5G and the type is c W95 FAT32 (LBA)
Processing output files
Producing stats
Creating list of files with counts
Cleaning up
Total elapsed time: 00:00:00:12

The image created with ddrescue contains the whole sd card, not only a partition. I ran fsck.exfat on the image with no errors - the filesystem seems to be intact. The partition inside the image can also be mounted without errors using an appropriate offset. The image file is a sparse file to safe space on an NTFS external hdd.

Is "exFAT" supported at all by ddru_findbad? Any ideas on how to proceed?

Thanks!

[Davison]

If your goal is simply to get a list of files that are damaged by incomplete recovery and you are having difficulty with the ddru_findbad tool, you can always fall back to a more brute force method that I used before discovering the ddrutility toolset.

The basics are:
1. Mount rescued image file and create a list of hashes for every file using hashdeep
2. Use ddrescue in fill-mode to fill all non-rescued areas of the image with a character string
3. Create a new list of hashes and then diff the two files containing the before and after hashes.

This will give you a list of any files that had contents modified by the fill-mode in the error areas which in theory would show precisely which files had unrecovered areas present. If you don't see any difference in the diff then (again in theory) it would mean that the error areas are not part of any files.

[j-sharp]

I already tried the "fill method" following the manual and got a list of broken files. Thanks anyway Davison.

The goal of my attempt using ddru_findbad is to get a list of bad sectors that are not allocated at all or to figure out which sectors exactly are related to files that are unimportant (or saved in a backup).

In the meantime I got it working by just using the -a option of ddru_findbad and setting the partition type to FAT manually. The output shows that all of the bad sectors are allocated.

I still want to speed-up the rescue process (I am getting only 4k in 15 hours out of the card) by creating a new logfile for ddrescue by marking bad sectors which belong to unimportant or backed-up files as "rescued". I would OR this new logfile (using ddrescuelog) with my existing logfile and continue with the resulting logfile the rescue operation, but now only working on the sectors that I really need.

Any ideas on how to turn the results_list.txt from ddru_findbad into a full-fledged logfile for ddrescue? I thought about the following:
1) Copy all sectors from results_list.txt to a new logfile. I guess I should use the number under "DeviceSector" as I rescued the whole card and not just only one partition.
2) Mark all unneeded sectors with + in the new logfile.
3) OR the new logfile with the existing logfile from ddrescue. Do I have to convert the existing sector numbers to hex first?
4) Continue ddrescue with the resulting logfile from the OR operation.

I am happy about any suggestions to my proposed approach. Would it would as intended?

[Davison]

I don't really have any experience with the ddru_findbad tool (only the ddru_ntfsfindbad tool) and I haven't been trying to convert and findbad results into sector locations (it also looks like the output of ddru_ntfsfindbad must be different than ddru_findbad). So I'm afraid I can't be much help--hopefully someone else can step in and offer advice.

[j-sharp]

results_list.txt has the following format:

Partition /dev/loop1p1 Type FAT DeviceSector 7902576 PartitionSector 7900528 Cluster 30861 Allocated yes Inode 41183 File /DCIM/Camera/20160706_120700_HDR.jpg
Partition /dev/loop1p1 Type FAT DeviceSector 7902577 PartitionSector 7900529 Cluster 30861 Allocated yes Inode 41183 File /DCIM/Camera/20160706_120700_HDR.jpg
...

So it's not a logfile that could be used by ddrescue directly. If I find a solution, I probably post its here in case anyone else comes across this some time.