← Back to team overview

duplicity-team team mailing list archive

[Question #670964]: AssertionError in add_filename - backup folder corrupted?

 

New question #670964 on Duplicity:
https://answers.launchpad.net/duplicity/+question/670964

deja-dup 37.1-2fakesync1
duplicity 0.7.17-0ubuntu1

My deja-dup backups have started to fail with "Failed with an unknown error.", accompanied by this traceback:

Traceback (innermost last):
  File "/usr/bin/duplicity", line 1555, in <module>
    with_tempdir(main)
  File "/usr/bin/duplicity", line 1541, in with_tempdir
    fn()
  File "/usr/bin/duplicity", line 1393, in main
    do_backup(action)
  File "/usr/bin/duplicity", line 1419, in do_backup
    action).set_values()
  File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line 710, in set_values
    self.get_backup_chains(partials + backend_filename_list)
  File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line 836, in get_backup_chains
    add_to_sets(f)
  File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line 824, in add_to_sets
    if set.add_filename(filename):
  File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line 105, in add_filename
    (self.volume_name_dict, filename)
 AssertionError: ({1: 'duplicity-inc.20180614T072154Z.to.20180615T072208Z.vol1.difftar.gz'}, 'duplicity-inc.20180614T072154Z.to.20180615T072208Z.vol1.difftar.gz')

It looks like Bug #1652410, where an uncompressed backup volume sits next to its compressed counterpart, but then I ran ls in the backup storage directory, which is on an NTFS formatted disk volume:

    kakurady@nanairo:/media/kakurady/Seagate Backup Plus Drive/Backup/nanairo$ ls duplicity-inc.20180614*
    ls: cannot access 'duplicity-inc.20180614T072154Z.to.20180615T072208Z.vol2.difftar.gz': No such file or directory
    duplicity-inc.20180614T072154Z.to.20180615T072208Z.manifest
    duplicity-inc.20180614T072154Z.to.20180615T072208Z.vol1.difftar.gz
    duplicity-inc.20180614T072154Z.to.20180615T072208Z.vol1.difftar.gz
    kakurady@nanairo:/media/kakurady/Seagate Backup Plus Drive/Backup/nanairo$ ls | grep "duplicity-inc\.20180614"
    duplicity-inc.20180614T072154Z.to.20180615T072208Z.manifest
    duplicity-inc.20180614T072154Z.to.20180615T072208Z.vol1.difftar.gz
    duplicity-inc.20180614T072154Z.to.20180615T072208Z.vol1.difftar.gz
    duplicity-inc.20180614T072154Z.to.20180615T072208Z.vol2.difftar.gz
    kakurady@nanairo:/media/kakurady/Seagate Backup Plus Drive/Backup/nanairo$ ls -i | grep "duplicity-inc\.20180614"
    ls: cannot access 'duplicity-inc.20180614T072154Z.to.20180615T072208Z.vol2.difftar.gz': No such file or directory
    ls: cannot access 'duplicity-inc.20180615T072208Z.to.20180616T072156Z.manifest': No such file or directory
    ls: cannot access 'duplicity-inc.20180615T072208Z.to.20180616T072156Z.vol1.difftar.gz': No such file or directory
    ls: cannot access 'duplicity-inc.20180615T072208Z.to.20180616T072156Z.vol2.difftar.gz': No such file or directory
    ls: cannot access 'duplicity-inc.20180616T072156Z.to.20180617T112221Z.manifest': No such file or directory
    ls: cannot access 'duplicity-inc.20180616T072156Z.to.20180617T112221Z.vol1.difftar.gz': No such file or directory
    ls: cannot access 'duplicity-inc.20180617T112221Z.to.20180618T111612Z.manifest': No such file or directory
    ls: cannot access 'duplicity-inc.20180617T112221Z.to.20180618T111612Z.vol1.difftar.gz': No such file or directory
    ls: cannot access 'duplicity-inc.20180618T111612Z.to.20180619T072208Z.vol1.difftar.gz': No such file or directory
    354308 duplicity-inc.20180614T072154Z.to.20180615T072208Z.manifest
    354305 duplicity-inc.20180614T072154Z.to.20180615T072208Z.vol1.difftar.gz
    354305 duplicity-inc.20180614T072154Z.to.20180615T072208Z.vol1.difftar.gz
        ? duplicity-inc.20180614T072154Z.to.20180615T072208Z.vol2.difftar.gz

As you can see, there are two files with the same file name, and there are directory listings whose corresponding files can't be accessed.

I'm not sure if I should report it to Bug #1652410, or create a new bug.  I could try fixing the problem myself, starting with running chkdsk on the volume, but I also feel duplicity could do more to make diagnosing this situation easier, and fixing up the directory that way would mean I can't give more information on this. What should I do next?

-- 
You received this question notification because your team duplicity-team
is an answer contact for Duplicity.