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