Comment 0 for bug 1252484

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
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
# 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.