I am seeing this bug, too. All I can add is that it seems to happen on a file which is not present in the original full backup. The original full backup can be restored (or at least does not bump out when restoring the directory where the file listed in the assertion error lives).
For the record, I am using Fedora and there is a bug in their bugzilla, too: https://bugzilla.redhat.com/show_bug.cgi?id=901420 There is also another entry on lauchpad which I found when googling for this problem: https://bugs.launchpad.net/ubuntu/+source/duplicity/+bug/1222661 Unfortunately, no resolution in any of these, but the problem looks pretty serious. ** Bug watch added: Red Hat Bugzilla #901420 https://bugzilla.redhat.com/show_bug.cgi?id=901420 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to duplicity in Ubuntu. https://bugs.launchpad.net/bugs/720525 Title: AssertionError: first.difftype != "diff" Status in Duplicity - Bandwidth Efficient Encrypted Backup: New Status in “duplicity” package in Ubuntu: Confirmed Bug description: Sometimes when restoring or backing up, duplicity will crash with an AssertionError similar to the following: Traceback (most recent call last): File "/usr/local/bin/duplicity", line 1236, in <module> with_tempdir(main) File "/usr/local/bin/duplicity", line 1229, in with_tempdir fn() File "/usr/local/bin/duplicity", line 1183, in main restore(col_stats) File "/usr/local/bin/duplicity", line 538, in restore restore_get_patched_rop_iter(col_stats)): File "/usr/local/lib/python2.5/site-packages/duplicity/patchdir.py", line 518, in Write_ROPaths for ropath in rop_iter: File "/usr/local/lib/python2.5/site-packages/duplicity/patchdir.py", line 491, in integrate_patch_iters final_ropath = patch_seq2ropath(normalize_ps(patch_seq)) File "/usr/local/lib/python2.5/site-packages/duplicity/patchdir.py", line 458, in patch_seq2ropath assert first.difftype != "diff", patch_seq AssertionError: [(('.duplicity', 'filelist') reg), (('.duplicity', 'filelist') reg)] One reported workaround is to delete ~/.cache/duplicity and try again. ================ Original Report: ================ Duplicity version: 0.6.06 Python version: 2.5.4 OS: OpenBSD 4.8 Remote filesystem: ext3 Local filesystem: ffs I've attached a verbose log of the duplicity output and errors. I've copied the backup files from the remote server to my local machine to rule out transmission issues. The python process spins for a bit at 0.1% CPU usage, but then stops and top's TIME column doesn't increase. It continues to hang after that until I kill it. As you can see in the log, there are several 'Operation not permitted' errors; however, the processing continues. Then there is an AssertionError, and that's the last thing that is displayed before the process hangs. Also, here is a list of the files and directories that were restored: restore restore/.Xdefaults restore/.cache restore/.cache/duplicity restore/.cache/duplicity/4d69b8815c980ca928f8bf0170d40bfb restore/.cache/duplicity/4d69b8815c980ca928f8bf0170d40bfb/duplicity-full-signatures.20110110T003018Z.sigtar.gz restore/.duplicity restore/.duplicity/backup.log Also, if there is a workaround so that I can retrieve my files, I'd greatly appreciate being pointed in the right direction. To manage notifications about this bug go to: https://bugs.launchpad.net/duplicity/+bug/720525/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
