Comment 5 for bug 713832

I performed a fresh re-installation of duplicity on the AMD 64bit Ubuntu machine and experienced my first successful backup (47k files, 127GB). Since I have done nothing to solve the problem, I can only suspect I will have the problem occur again at a later time.

The corruption definitely occurs during the backup phase, because multiple attempts at restoring the same a backup duplicity archive fails identically. Each attempt at creating a new backup duplicity archive results in a different point of corruption during the subsequent restore process.

The system I used is an AMD 64-bit running Ubuntu. Because of the zlib compression failures, I had modified the gpg source to use the latest zlib library (as opposed to the version with known exploits shipped within the code itself). Also, the target dest and src duplicity drives are local USB hard drives. This may be important if file flushing/syncing is managed differently from the kernel OS -- I had been suspecting a race condition that upon the gpg thread termination the output stream had not flushed, and the subsequent thread execution of md5/sha produced a signature over less than the entire file. If I experience the md5/sha mismatch again, I will perform a byte by byte reconstruction of the file signature to see if the incorrect signature exists within the original file.

-W