(OS X) Error starting DDRescue

[Hamish McIntyre-Bhatty]

I'm kind of a newbie trying to use this on my Mac, OS X 10.11.6.

I've previously used ddrescue on the command line with some success, but I was hoping DDRescue-GUI would be an easier way to rescue an entire disk rather than single files. However, no matter what I choose in the drop-down menus, it never seems to get past the "Preparing to start ddrescue…" stage. I've read Bug #1614228, but it talks about "when selecting a non-device input file" and I try to select the device descriptor (/dev/disk4/) rather than the partition (/dev/disk4/s2) and the result is the same. I also tried running the current Github source, but there is no difference.

I'm probably doing something wrong. I'd also prefer to not involve any image files at all, and just write files directly to the destination disk (Creating an image file seems like a completely unnecessary extra stage, why would anyone want to do this?). I managed to do this from the command line by first recreating the folder hierarchy from the problem disk, then using find in order to run ddrescue on every file in every folder. This worked, but I found out that there were some files among the thousands copied that it was unable to rescue 100 percent, but it was nearly impossible to find out which ones those were after the fact.

It seems like such a typical user case: I want to rescue as many files as possible from the failing drive, but if some files can only be recovered to 98 percent, I really want to know about it. There must be others who have wanted to do this, there has to be scripts out there that do exactly this, but Google fails me.

EDIT:
In the Terminal output from running the latest git version, I get this:

DDRescue-GUI Version 1.6.1 Starting...
2016-10-01 09:39:06.223 Python[7249:97542] plugin com.getdropbox.dropbox.garcon interrupted
2016-10-01 09:39:06.223 Python[7249:97455] Hub connection error Error Domain=NSCocoaErrorDomain Code=4097 "connection to service named com.getdropbox.dropbox.garcon" UserInfo={NSDebugDescription=connection to service named com.getdropbox.dropbox.garcon}
Traceback (most recent call last):
  File "/Users/administrator/Downloads/ddrescue-gui-master/DDRescue-GUI.py", line 1012, in OnControlButton
    self.OnStart()
  File "/Users/administrator/Downloads/ddrescue-gui-master/DDRescue-GUI.py", line 1035, in OnStart
    if BackendTools().IsMounted(Disk) or DevInfoTools().IsPartition(Disk) == False:
  File "/Users/administrator/Downloads/ddrescue-gui-master/Tools/tools.py", line 57, in IsMounted
    MountInfo = self.StartProcess("mount", ReturnOutput=True)[1]
  File "/Users/administrator/Downloads/ddrescue-gui-master/Tools/tools.py", line 39, in StartProcess
    logger.debug("Tools: Main().StartProcess(): Process: "+Command+": Return Value: "+unicode(Retval)+", Output: \"\n\n"+''.join(Output)+"\"\n")
UnicodeDecodeError: 'ascii' codec can't decode byte 0xcc in position 28: ordinal not in range(128)

[Hamish McIntyre-Bhatty (hamishmb)]

Hi,

Thanks for this report, very comprehensive and makes my job much easier. Could you post the output of "mount" for me please? There seems to be something strange going on when DDRescue-GUI runs that command, but I can't yet figure out what's going wrong.

Thanks,
Hamish

[Petter Sjolund (stolle1234)]

Heh, some people would call it rambling. I guess I was frustrated when I wrote it. Then, all of a sudden, it started to work. I don't know what changed. I compiled my own WX, among other things. I don't know if that could have made any difference. Then my failing drive broke down completely, so I kind of lost interest.

Anyway, here is my output of mount:
administrator$ mount
/dev/disk1 on / (hfs, local, journaled, noatime)
devfs on /dev (devfs, local, nobrowse)
map -hosts on /net (autofs, nosuid, automounted, nobrowse)
map auto_home on /home (autofs, automounted, nobrowse)
localhost:/TAwhOYROM3xUB_lzBuJNlN on /Volumes/MobileBackups (mtmfs, nosuid, read-only, nobrowse)
/dev/disk4s2 on /Volumes/Tidsmaskin (hfs, local, nodev, nosuid, journaled)
/dev/disk2s2 on /Volumes/Eld (hfs, local, nodev, nosuid, journaled, noowners)

[Petter Sjolund (stolle1234)]

Also, the drive that broke down had a unicode character in its name ("Tvåan") which might explain that unicode error.

[Hamish McIntyre-Bhatty (hamishmb)]

Hi,

Thanks -- that clears it up for me, I hadn't thought about unicode characters in volume names, I'll need to look into that. Probably what happened is it started working cos the drive unmounted and stopped appearing in the output.

Rambling when it comes to bug reports is good XD Sorry to hear about that, but hope you still have that data you pulled off before. Marking this as verified and medium priority cos it no longer actively affects anyone :)

Hamish

[Hamish McIntyre-Bhatty (hamishmb)]

As it stands at the moment, this is partially fixed, but I can't fully fix it due to what seem to be issues with the plist parser in Python, so further research will be needed. This will hopefully be fixed in the next release, 1.7.1/1.8.

[Hamish McIntyre-Bhatty (hamishmb)]

Can't fix due toa bug in python 2.7's plistlib, will fix when the project migrates to python 3.x

[Hamish McIntyre-Bhatty (hamishmb)]

py3 now supported, need to re-test.

[Hamish McIntyre-Bhatty (hamishmb)]

I can confirm that this error doesn't occur on Python3. Yay for proper unicode support! This will be fixed in the next release, because the Mac build will be Python3-only. On Linux, this may/may not be a problem cos we're stuck on Python 2 until distros adopt the new wxPython. I'll mark this as fix committed for now.

[Hamish McIntyre-Bhatty (hamishmb)]

Okay, wxPython 4 for Python 3 has landed in new versions of Ubuntu and Fedora, and the currently-in-development new version has been made to work with that configuration. This bug may still exist under Python 2 on Linux, but I'm yet to have found it.

[Hamish McIntyre-Bhatty (hamishmb)]

This fix has been release, as DDRescue-GUI 2.0.0 (Python 3-only builds on macOS) has been released!

[Petter Sjolund (stolle1234)]

Great work!