bobdbitbucket@netscape.net (Bob) wrote in message news:<e6696cf0.0407050550.3a183167@posting.google. com>...
>
> I had a vfat partition develop some bad blocks. I used ddrecover to copy what
> was salvagable (i.e. most of it - 29GB - 32KB) to another disk. It
> encountered 64 bad blocks, ... So I'd like to know which of the files
> I've "recovered" are actually corrupted because they contained one of the
> bad blocks, ...

If you still have access to the bad medium, the following might work,
assuming at least one copy of the FAT is good on the partition: the
following technique depends on the operating system (and then the
application) reporting a failed read caused by a bad sector, which
I've found is most often the case.

$ su root
# mkdir -p /bad
# mount -t vfat /dev/bad_part /bad
# find /bad/ -exec dd if='{}' of=/dev/null ';' \
2>/var/tmp/bad_files.log

Notice that we're giving every file on the partition individually to
the 'dd' command, logging the errors. The 'if=file of=/dev/null' part
will attempt to read all the data of the file, and when the vfat
driver encounters a bad sector, this error should cause 'dd' to stop
processing the file and then report the error, which will be logged to
'/var/tmp/bad_files.log'. Notice I did not specify the 'conv=noerror'
option to dd since we want the errors to be logged. See dd(1).

Of course, you could also use ddrecover or whatever utility you used,
in place of 'dd' as I showed in that example; as long as the utility
reliably reports a failed read (with the filename) to the stderr (fd
2), that technique should give you a log of all the bad files.