2

So I'm having this error which apparently is a known issue. I'm looking for a work-around until it's fixed because I can't afford to go without systems backup.

Traceback (most recent call last):
  File "/usr/bin/duplicity", line 1532, in <module>
    with_tempdir(main)
  File "/usr/bin/duplicity", line 1526, in with_tempdir
    fn()
  File "/usr/bin/duplicity", line 1380, in main
    do_backup(action)
  File "/usr/bin/duplicity", line 1401, in do_backup
    sync_archive(decrypt)
  File "/usr/bin/duplicity", line 1139, in sync_archive
    remote_metafiles, ignored, rem_needpass = get_metafiles(remlist)
  File "/usr/bin/duplicity", line 1029, in get_metafiles
    pr = file_naming.parse(fn)
  File "/usr/lib/python2.7/dist-packages/duplicity/file_naming.py", line 400, in parse
    pr = check_inc()
  File "/usr/lib/python2.7/dist-packages/duplicity/file_naming.py", line 340, in check_inc
    t1 = str2time((m1 or m2).group("start_time"), short)
  File "/usr/lib/python2.7/dist-packages/duplicity/file_naming.py", line 290, in str2time
    t = dup_time.genstrtotime(timestr.upper())
  File "/usr/lib/python2.7/dist-packages/duplicity/dup_time.py", line 295, in genstrtotime
    return override_curtime - intstringtoseconds(timestr)
  File "/usr/lib/python2.7/dist-packages/duplicity/dup_time.py", line 203, in intstringtoseconds
    error()
  File "/usr/lib/python2.7/dist-packages/duplicity/dup_time.py", line 194, in error
    raise TimeException(bad_interval_string % interval_string)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe3 in position 0: ordinal not in range(128)

Related issues:

  • What is your source code? What commands produce this error? – Theoremiser Apr 7 '17 at 20:01
  • Using the backups GUI produces it. I think I've seen it at the command line though. – user447607 Apr 7 '17 at 20:27
5

The core problem is Unicode strings - you've got them somewhere, and Duplicity (or at least, the version you're using possibly) is not configured to handle Unicode strings properly. This is due to the caveats of Python 2.


In Python 2, there are two separate "string" type classes:

  • str - This is the typical standard ASCII codec seen in many systems, and is more or less just the standard A-Z, 0-9, some symbols from the keyboard set of characters.

  • unicode - This is the UTF-8 encoding, the UTF-16, etc. encodings, which have a huge range of international characters, emojis, etc.

Whatever is being passed to Duplicity, in this case, us likely using a character from the UTF charsets that is outside the standard ASCII range of characters. This is why we get a UnicodeDecodeError in the traceback - we're trying to convert Unicode strings to ASCII strings, and we can't due to characters being outside the ASCII character sets.


I would suggest filing a bug in Duplicity to make a note they don't handle Unicode properly, but I would also look at whatever files Duplicity is handling and make sure you don't have any Unicode characters (or hidden secret control characters) in the strings it's trying to work with.

NOTE: According to the bugs linked, this is already fixed; it's possible that this was fixed in a later version of Deja-Dup, but not the version you are using, in which case you would need to find a Backported or Updated version to work around the error.

On one of the bugs, a workaround of renaming filenames with foreign character sets in the Unicode set should be renamed to ASCII-only filenames, for DejaDup to handle them properly. That's the only known workaround, short of updating to a newer DejaDup verison.

  • 1
    Apparently there already is one. – user447607 Apr 7 '17 at 19:53
  • @user447607 Then all you can do is wait - I would share the link, here, in a comment though so we can link to the existing bug in this answer, in case people want to status-check the state of this bug. (Note that if this were a Python 3 program, the error wouldn't exist, because str is Unicode by default in Python 3, and not a separate unicode variable type class.) – Thomas Ward Apr 7 '17 at 19:55
  • Instead I rewrote asking for a work-around. Business still has to get done, if possible. – user447607 Apr 7 '17 at 19:59
  • @user447607 The workaround is to rename things with unicode chars to non-Unicode filenames - that way you don't hit the decode error. I've added that to my answer. – Thomas Ward Apr 7 '17 at 20:00
  • What "things" ? File names? AFIK, there aren't any. I don't speak German. Music is one possibility but it's excluded from this backup because I handle it elsewhere. – user447607 Apr 7 '17 at 20:01
0

Make sure you use the latest release 0.7.12, as there were some improvements in this regard.

Looks like duplicity tries to raise a TimeException, but stumbles over printing the error translation.

The current workaround should be setting LC_ALL env var to prohibit duplicity translating and using the default english strings. Either export the setting or put it in front of your duplicity call, like so

LC_ALL=C duplicity ...

This of course won't solve the error, but at least show what the error (TimeException) is caused by.

..ede/duply.net

  • Nope. Fails with different error. Will restart and double check. – user447607 Apr 9 '17 at 17:08
  • I've looked at the shortcut and the actual command is "deja-dup --backup" – user447607 Apr 9 '17 at 17:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.