Comment 28 for bug 487720

I also see this (or something a lot like it) when restoring from S3. It consistently fails at the same point.

Writing presentations/karl-lp-slides/.bzr/repository/pack-names of type reg
Writing presentations/karl-lp-slides/.bzr/repository/packs of type dir
Making directory /home/mbp/restore2/presentations/karl-lp-slides/.bzr/repository/packs
Writing presentations/karl-lp-slides/.bzr/repository/packs/333f31809d404f88307e43ab55aba6b6.pack of type reg
Deleting /tmp/duplicity-nZZdPB-tempdir/mktemp-G1Aa_U-107
Processed volume 104 of 119
Downloading s3+http://mbp.lithe.dy.sourcefrog.net//duplicity-full.20101017T064647Z.vol74.difftar.gpg
Invalid data - SHA1 hash mismatch:
Calculated hash: 0f562b0a57965ccde134263ebee44b8c07e630aa
Manifest hash: bfa0dc7844e1e565b8b34487e5832687d734cb9e

From my understanding of S3, I would not expect it to ever show just a partial file in place: uploads should appear atomically. However, I might be wrong, or there might be something in boto that causes this to happen.

Adding the current date to -t does not fix the problem. I'm going to try setting -t back to before the last increment.