I should note for anyone experiencing any of the symptoms of this bug when restoring [1], this fix does not let you get back the 65k chunk of data that this bug lost. But duplicity trunk contains some additional fixes that should let you restore the rest of your data. That is, duplicity trunk no longer throws an exception when encountering the symptoms of this bug. It will continue to restore the data not affected by this bug.
So while you can't experience full relief, duplicity trunk will let you recover most things. [1] It can cause various exceptions depending on how/when this bug happened; see the duplicate bugs. -- 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/1252484 Title: Possible data loss when restarting in the middle of a deleted file Status in Duplicity - Bandwidth Efficient Encrypted Backup: Fix Committed Status in “duplicity” package in Ubuntu: Fix Released Status in “duplicity” source package in Lucid: Fix Committed Status in “duplicity” source package in Precise: Fix Committed Status in “duplicity” source package in Quantal: Fix Committed Status in “duplicity” source package in Raring: Fix Committed Status in “duplicity” source package in Saucy: Fix Released Bug description: This was recently fixed in duplicity trunk. But I'm filing a bug for paperwork purposes and for Ubuntu SRUs. [Impact] When restarting a backup, duplicity may accidentally skip the first 65k chunk of one of the source files. This means that when it is restored, it will be incomplete/corrupted, resulting in data loss. [Test Case] Download and install the 'test1.sh' file attached to this bug report, and run it like 'sh test1.sh'. If it prints the following line, the bug is present: Binary files /tmp/source/newfile and /tmp/restore/newfile differ Or, follow these manual steps: mkdir /tmp/source dd if=/dev/urandom of=/tmp/source/bigfile bs=1024 count=5000 # This next command will intentionally fail after the second volume! duplicity full /tmp/source file:///tmp/backup --vol 1 --fail 2 --no-encryption mv /tmp/source/bigfile /tmp/source/newfile duplicity full /tmp/source file:///tmp/backup --no-encryption duplicity restore file:///tmp/backup /tmp/restore --no-encryption # This next line will say the files differ if the bug is present diff /tmp/source/newfile /tmp/restore/newfile [Regression Potential] It's a relatively small patch, only affecting the specific case of restarting a backup when the file we were in the middle of is no longer there. I'd say minor regression potential. To manage notifications about this bug go to: https://bugs.launchpad.net/duplicity/+bug/1252484/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
