Comment 6 for bug 1091269

Not a clue. What's get_footer()? We did not encounter this problem
because duplicity has not been used much in no-encryption mode before now.
 I'm still unclear why anyone would want to do so. Kind of like using a
wrench to drive in a nail.

On Sat, Jan 5, 2013 at 10:35 AM, Michael Terry
<email address hidden>wrote:

> It looks like all the files that have problems are files split across
> volumes. So I posit that since the amount to read from the input files
> is based on how close the gzipped volume is to our target size (see
> GzipWriteFile()), that amount to read could be different if the gzip
> compression is different across runs. And it might be different if it
> includes the timestamp? Or uses a random number generator seeded from
> the timestamp or some such.
>
> That would also explain why this patch fixes the issue. With this
> patch, we always read exactly 128*1024 bytes (though the code could be
> clearer about that).
>
> I'm looking into this further, trying to add an automatic test for this.
>
> In slightly unrelated news, why does GzipWriteFile() not call
> "gzip_file.write(block_iter.get_footer())"?
>
> --
> You received this bug notification because you are subscribed to
> duplicity in Ubuntu.
> https://bugs.launchpad.net/bugs/1091269
>
> Title:
> Data corruption when resuming with --no-encryption option
>
> Status in Duplicity - Bandwidth Efficient Encrypted Backup:
> Fix Committed
> Status in “duplicity” package in Ubuntu:
> New
>
> Bug description:
> I have found a bug similar to #613244.
>
> It seems that some files are corrupted when the backup is interrupted
> and resumed when using --no-encryption option.
>
> The make-ctrl-c-test.sh test fails if I add the --no-encryption option
> to duplicity. Without this option it works fine.
>
> I have added an option to make-ctrl-c-test.sh test to run it with or
> without encryption (patch attached).
>
> I have seen this bug in the current duplicity quantal version
> (0.6.19-0ubuntu2) and in the last bazaar revision (897).
>
> I also attached a patch that seems to fix this issue. I don't know
> anything about duplicity internals, so I don't know if this patch is
> correct or it will break something. Actually, I have ran the run-test
> script and it fails in test_GzipWriteFile test. But hopefully this can
> help you to fix the problem.
>
> These are the final log lines of the make-ctrl-c-test.sh script, with
> and without encryption.
>
> make-ctrl-c-test.sh with encryption:
> ...
> Restoring backups...
> Local and Remote metadata are synchronized, no sync needed.
> Last full backup date: Mon Dec 17 14:07:59 2012
> Local and Remote metadata are synchronized, no sync needed.
> Last full backup date: Mon Dec 17 14:08:13 2012
> Diff between /lib and /tmp/restore1
> Diff between /tmp/restore1 and /tmp/restore2
>
> make-ctrl-c-test.sh with --no-encryption and without fix applied:
> ...
> Restoring backups...
> Local and Remote metadata are synchronized, no sync needed.
> Last full backup date: Mon Dec 17 14:08:55 2012
> Local and Remote metadata are synchronized, no sync needed.
> Last full backup date: Mon Dec 17 14:09:16 2012
> Diff between /lib and /tmp/restore1
> Diff between /tmp/restore1 and /tmp/restore2
> Files
> /tmp/restore1/modules/3.5.0-19-generic/kernel/drivers/infiniband/hw/qib/ib_qib.ko
> and
> /tmp/restore2/modules/3.5.0-19-generic/kernel/drivers/infiniband/hw/qib/ib_qib.ko
> differ
>
> make-ctrl-c-test.sh with --no-encryption and fix applied:
> ...
> Restoring backups...
> Local and Remote metadata are synchronized, no sync needed.
> Last full backup date: Mon Dec 17 14:19:43 2012
> Local and Remote metadata are synchronized, no sync needed.
> Last full backup date: Mon Dec 17 14:20:14 2012
> Diff between /lib and /tmp/restore1
> Diff between /tmp/restore1 and /tmp/restore2
>
> The test_GzipWriteFile fails with this error:
> ======================================================================
> FAIL: test_GzipWriteFile (__main__.GPGTest)
> Test GzipWriteFile
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "tests/gpgtest.py", line 135, in test_GzipWriteFile
> assert size - 64 * 1024 <=
> os.stat("testfiles/output/gzwrite.gz").st_size <= size + 64 * 1024
> AssertionError
>
> ----------------------------------------------------------------------
> Ran 8 tests in 1.326s
>
> FAILED (failures=1)
> Test failed
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/duplicity/+bug/1091269/+subscriptions
>