Merge lp:~mterry/deja-dup/gio-mount-password into lp:deja-dup/22
Status: | Merged |
---|---|
Merged at revision: | 1306 |
Proposed branch: | lp:~mterry/deja-dup/gio-mount-password |
Merge into: | lp:deja-dup/22 |
Diff against target: |
208 lines (+61/-16) 7 files modified
common/Backend.vala (+1/-1) common/BackendAuto.vala (+1/-1) common/BackendFile.vala (+44/-1) common/BackendRackspace.vala (+1/-1) common/BackendS3.vala (+1/-1) common/BackendU1.vala (+1/-1) common/Duplicity.vala (+12/-10) |
To merge this branch: | bzr merge lp:~mterry/deja-dup/gio-mount-password |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Ken VanDine | Approve | ||
Review via email: mp+98561@code.launchpad.net |
This proposal supersedes a proposal from 2012-03-19.
Description of the change
If duplicity is run under sudo (as happens when non-home data is backed up), it can't use the user's remote mount. So it previously just aborted. This branch works around that.
To test:
* Setup Deja Dup like so:
- Include "/bin"
- Make your backup location a remote GVFS location that needs a password, like an FTP server or SSH server
* Make a backup
* Try to restore (./deja-
Before the patch:
* You should get prompted for your root password and it will fail with "Connection failed, please check your password: Login dialog cancelled"
After the patch:
* You should get *not* get prompted for your root password and it will restore, even though nothing got restored (this is a bug -- I need to make it warn about all the files that didn't get restored)
Hrm, this needs some more thinking. If a user mounts the location first, but does not save the mount info in the keyring, we have no way to get to it. Seems awkward that we're being punished for using the standard GNOME mount infrastructure, but there ya go.