** Description changed: 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] 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 --no-encryption full /tmp/source file:///tmp/backup --vol 1 --fail 2 + duplicity full /tmp/source file:///tmp/backup --vol 1 --fail 2 --no-encryption mv /tmp/source/bigfile /tmp/source/newfile - duplicity --no-encryption full /tmp/source file:///tmp/backup - duplicity --no-encryption restore file:///tmp/backup /tmp/restore + 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.
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1252484 Title: Possible data loss when restarting in the middle of a deleted file To manage notifications about this bug go to: https://bugs.launchpad.net/duplicity/+bug/1252484/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
