Merge lp:~mterry/duplicity/catch-seq-copy-error into lp:duplicity/0.6
Status: | Merged |
---|---|
Merged at revision: | 929 |
Proposed branch: | lp:~mterry/duplicity/catch-seq-copy-error |
Merge into: | lp:duplicity/0.6 |
Diff against target: |
40 lines (+15/-6) 1 file modified
duplicity/patchdir.py (+15/-6) |
To merge this branch: | bzr merge lp:~mterry/duplicity/catch-seq-copy-error |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Peter Fenton (community) | Needs Fixing | ||
duplicity-team | Pending | ||
Review via email: mp+186106@code.launchpad.net |
Description of the change
When converting a sequence of patches to a ROPath, sometimes duplicity wants to collapse the current set of patches into a temporary file for librsync's benefit, because it has encountered a non-true-
When this happens, if an error occurs, the exception is not caught and will terminate duplicity.
If that same error happened lazily -- as it normally does if duplicity doesn't decide to collapse patches into a temporary file -- the exception is caught, like many others, by IterTreeReducer's handlers and is merely logged while the rest of duplicity chugs along.
Ideally these two cases would be handled more similarly. It makes bugs like bug 662442 much worse than they need to be because a problem with a single file prevents restoring the whole backup.
This branch captures common errors that occur during the patch-collapsing, logs them, and moves on. Behavior is still not *identical* between the two cases [1], but it's much better.
[1] For example, if you are restoring only one file, the fact that this branch treats files with collapsing problems as non-existent means that duplicity will say it didn't find any files to restore -- whereas the normal path will recognize that it at least found a file. This didn't seem like a huge problem and would have been a little awkward to fix (maybe have seq2ropath return a ticking-time-bomb ROPath that would raise its error next time it was used? Seemed hackier than this branch).
I've updated this branch to use a simpler, more generic approach.
*Any* exception when running patch_seq2ropath should be ignored (though logged) and duplicity should move on. This covers the two asserts in that function (bug 1155345 and bug 720525) as well as errors that happen during file copying (bug 662442).
This doesn't solve any of those bugs, obviously. But it makes them less severe.
I'm getting the feeling that all three bugs have the same root cause: a missing sequence object. 662442 can be explained by a missing patch in the sequence, and the other two can be explained by a missing first snapshot...