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
>