duplicity-team team mailing list archive

[Michael Terry <mike@xxxxxxxxxxx>]

Hello!  I was looking at
https://bugs.launchpad.net/deja-dup/+bug/487720 again, which I'll
summarize.  If something goes wrong when backing up, a partial file
can get left on the backup target.  This partial file confuses
duplicity and the sha1 sum for the partial file doesn't match what
duplicity expects for the complete file and the user gets "Invalid
data - SHA1 hash mismatch".

Now, it was originally thought this only affected ssh.  I think more
accurately, it affects at least the gio and local backends.  The
original report was from Deja Dup using the gio backend.  Various
me-toos on the bug have discussed smb (I know that reporter was using
gio), ftp, and s3.

For gio, a temporary file will only be used if the target file already
exists.  Otherwise it just writes directly to the target.  Local
(file://) targets always just write directly.

A naive approach would be to add an extra layer to backend.py that
says if there was an exception during a write, delete any partial
target file that may have been written.  But that wouldn't really
solve all cases like computer shutting down or a kill signal to
duplicity.

Would it make sense to augment the resume code to check the sha1sum of
the most recent chunk and restart that chunk if the sums don't match?

-mt