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 protected]>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 > -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1091269 Title: Data corruption when resuming with --no-encryption option To manage notifications about this bug go to: https://bugs.launchpad.net/duplicity/+bug/1091269/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
