Re: DDRescue screwed up on NTFS drive backup, partition won't read now

[Antonio Diaz Diaz]

Hi Travis,

Travis Sherwood wrote:
> Thank you for replying so promptly. The exact tool I performed the
> procedure with is DDRescue-GUI, found here: https://www.hamishmb.com/

I have never used DDRescue-GUI (nor any other GUI frontend). I prefer to 
interact directly with ddrescue from the command line.

> So far, the consensus has been that the Source and Destination drives
> were switched around. As for how this occurred, I have no idea because
> the procedural matters left zero chance for human error. The WD Elements
> drive never gets unplugged and is the only external drive used on this
> system. This rules out any possibility of it changing its designation
> from SDB to anything else.

I'm sure you were diligent. The only explanation I can find is that between 
your selection of drives in DDRescue-GUI and the actual call to ddrescue, 
some automatic feature of the kernel or of Ubuntu managed to switch the 
device names. I still use linux 3.2 and have removed all automation from my 
system. I mount devices by hand, etc.

> But since the One in a Million chance did happen, a final Confirmation
> Message to list Source (Designation and Description), Destination
> (Designation and Description) and Procedure seems like the simplest
> solution to prevent this from occurring again. Do you think this could be
> implemented in the next version?

Ddrescue already implements a final confirmation with the option --ask:

$ ddrescue -f --ask /dev/sda /dev/sdb
GNU ddrescue 1.27-pre1
About to copy 500107 MBytes
from '/dev/sda' [SAMSUNG HD502IJ::S13TJ9BS200514] (488_386_584Ki)
  to '/dev/sdb' [SAMSUNG SV1022D::0255J1EN821966] (10_203_684_352)
Proceed (y/N)?

Maybe Hamish could make DDRescue-GUI pass the option --ask to ddrescue so 
that the user has a chance to abort the copy if something changed in the 
last minute.

I am sorry for your trouble and I hope you can recover your data.

Best regards,
Antonio.