Merge lp:~mterry/duplicity/more-accurate-sync into lp:duplicity/0.6
Status: | Merged |
---|---|
Merged at revision: | 762 |
Proposed branch: | lp:~mterry/duplicity/more-accurate-sync |
Merge into: | lp:duplicity/0.6 |
Diff against target: |
64 lines (+13/-19) 1 file modified
duplicity-bin (+13/-19) |
To merge this branch: | bzr merge lp:~mterry/duplicity/more-accurate-sync |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
duplicity-team | Pending | ||
Review via email: mp+68884@code.launchpad.net |
Description of the change
The current sync'ing code breaks down a bit if you don't correctly tell duplicity whether to use encryption.
You'll see that if you have an archive of unencrypted backups, clear your cache, then run, say, collection-status against the archive (without passing --no-encryption), that you'll get an error saying duplicity couldn't find duplicity-
The reason is because duplicity breaks down what it sees on the backend (sigtar.gz) then builds a filename back up again based on what it would expect to see due to the command line (in this case, sigtar.gpg). This seems a bit willfully ignorant of information it already has.
This branch will always sync what is actually on the remote end, not what we thought would be there.
Of course, the rest of duplicity will handle the mismatch with more or less grace, but this particular error seemed obscure and unnecessary.