Skip to main content

duplicity suddenly fails with Python tuple error [Resolved]

I have been using duplicity in a cron job for a year now, has worked just fine. Starting from last week I got the following message:

Ausdruckbasierte Dateiliste wird gelesen /home/mu/.config/exclude-b2.txt
Traceback (most recent call last):
  File "/usr/bin/duplicity", line 1637, in 
    if "Forced assertion for testing" in util.uexc(e):
  File "/usr/lib64/python2.7/site-packages/duplicity/util.py", line 82, in uexc
    return ufn(m)
  File "/usr/lib64/python2.7/site-packages/duplicity/util.py", line 63, in ufn
    return filename.decode(globals.fsencoding, 'replace')
AttributeError: 'tuple' object has no attribute 'decode'

The last upgrade to the duplicity package on my Fedora 30 system has been 2019-05-09, I am running version 0.7.19. The backup goes to Backblaze B2.

Is there some way that I can get this pinned down?


Question Credit: Martin Ueding
Question Reference
Asked August 21, 2019
Tags: duplicity
Posted Under: Unix Linux
12 views
2 Answers

This is another instance where an interrupted backup leaves duplicity in a state where it cannot recover. I have deleted the partial files from the last incremental backup and now it works again.


credit: Martin Ueding
Answered August 21, 2019

Looking at the source downloadable from gnu, it seems it is trying to handle an exception, and getting an exception whilst doing so, which is not helpful. I think you are in the very last lines of /usr/bin/duplicity:

except Exception as e:
    util.release_lockfile()
    if "Forced assertion for testing" in util.uexc(e):
        log.FatalError(u"%s: %s" % (e.__class__.__name__, util.uexc(e)),
                       log.ErrorCode.exception,
                       e.__class__.__name__)
    else:
        # Traceback and that mess
        log.FatalError(util.exception_traceback(),
                       log.ErrorCode.exception,
                       e.__class__.__name__)

It calls util.uexc(e) to look for some text that is only used during testing (apparently), and this routine is failing for some reason. You can try just changing the if to start if False and instead to bypass this test and see if you then get the real cause of the exception logged. You might also try changing to the C locale temporarily to see if that changes anything.


credit: meuh
Answered August 21, 2019
Your Answer
D:\Adnan\Candoerz\CandoProject\vQA