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,

Reply via email to