Merge lp:~mterry/duplicity/report-encrypted-chains into lp:duplicity/0.6
Status: | Merged |
---|---|
Merged at revision: | 763 |
Proposed branch: | lp:~mterry/duplicity/report-encrypted-chains |
Merge into: | lp:duplicity/0.6 |
Diff against target: |
29 lines (+4/-1) 1 file modified
duplicity/collections.py (+4/-1) |
To merge this branch: | bzr merge lp:~mterry/duplicity/report-encrypted-chains |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
duplicity-team | Pending | ||
Review via email: mp+68885@code.launchpad.net |
Description of the change
For Deja Dup, I'm trying to support automatically detecting whether a backup is encrypted or not. This is useful especially when restoring so we can ask one less question of the user.
There are several ways to do this, none of which need work on top of today's duplicity:
1) I could watch for the debug message that prints the list of files we found on the backend and look at the suffixes. (WORK NEEDED: make that message machine-parsable; DISADVANTAGES: suffix information would need to be kept in Deja Dup)
2) I could have duplicity not return collection-status information for mismatched encryption states (e.g. if --no-encryption is passed, don't return any encrypted sets in the results). Then Deja Dup would just run collection-status at most twice to see which one returned results. (WORK NEEDED: make duplicity ignore mismached states, which is a trivial two-liner; DISADVANTAGES: seems less useful than it could be for human users and requires at most two passes for machine users)
3) I could have duplicity report in collection-status output whether a backup set is encrypted (but still return results even in a mismatch). (WORK NEEDED: make duplicity note and report encryption status for backup sets; DISADVANTAGES: none?)
So this branch implements #3. But let me know if you prefer the others and I can whip them up.
Ahem, of course I meant "all of which need work..."