Comment 5 for bug 1091269
Revision history for this message
| Michael Terry (mterry) wrote Re: Data corruption when resuming with --no-encryption option | #5 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
35a32c5
(Get the code!)
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.