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 _______________________________________________ Mailing list: https://launchpad.net/~duplicity-team Post to : [email protected] Unsubscribe : https://launchpad.net/~duplicity-team More help : https://help.launchpad.net/ListHelp
