Merge lp://qastaging/~mterry/duplicity/giobackend-display-name-0.7 into lp://qastaging/~duplicity-team/duplicity/0.8-series
| Status: | Superseded |
|---|---|
| Proposed branch: | lp://qastaging/~mterry/duplicity/giobackend-display-name-0.7 |
| Merge into: | lp://qastaging/~duplicity-team/duplicity/0.8-series |
| Diff against target: |
1277 lines (+477/-47) (has conflicts) 7 files modified
CHANGELOG (+24/-0) Changelog.GNU (+22/-0) bin/duplicity (+11/-0) duplicity/backends/giobackend.py (+13/-4) duplicity/collections.py (+39/-0) po/duplicity.pot (+348/-43) testing/unit/test_collections.py (+20/-0) Text conflict in CHANGELOG Text conflict in Changelog.GNU Text conflict in bin/duplicity Text conflict in duplicity/collections.py Text conflict in po/duplicity.pot Text conflict in testing/unit/test_collections.py |
| To merge this branch: | bzr merge lp://qastaging/~mterry/duplicity/giobackend-display-name-0.7 |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| duplicity-team | Pending | ||
|
Review via email:
|
|||
This proposal has been superseded by a proposal from 2017-08-05.
Description of the change
I was doing some testing on the google-drive: GIO backend (this is not the gdoc: duplicity backend, but rather using GNOME's abstraction layer to talk to Google through the giobackend code) and noticed some problems.
(A) Getting a list of files was broken because this backend chooses to use internal IDs for all its filename. Only the display_name() call gets the real user-set filename. Which, OK. We can use that instead. This will work for google-drive: as well as all other backends, since that is the user-set/
(B) Getting files wasn't working because we had been passing NOFOLLOW_SYMLINKS. Apparently the google-drive: backend treats all internal files as symlinks to other internal files? Doesn't matter, we can avoid having to care about what a backup does in that regard by simply not passing that flag. It was a level of precaution that we don't really need. Normally, duplicity will always be dealing with real files. If it's trying to get a symlink, it's because the user manually created one. In which case, maybe we should follow it, since the user wants us to.
Together, these fixes let google-drive: work (and maybe other similarly bizarre GIO backends). I also tested on a couple other backends (SSH and local) and they worked fine still.
Unmerged revisions
- 1305. By Michael Terry
-
giobackend: handle a wider variety of gio backends by making less assumptions; in particular, this fixes the google-drive: backend
- 1304. By Kenneth Loafman
-
* Fixed encrypted remote manifest handling to merely put out a non-fatal
error message and continue if the private key is not available. - 1303. By Kenneth Loafman
-
* Comment out profiling code.
- 1302. By Kenneth Loafman
-
* Fixed slowness in 'collection-status' by basing the status on the
remote system only. The local cache is treated as empty. - 1301. By Kenneth Loafman
-
* Fix date of last change.
- 1300. By Kenneth Loafman
-
* Merged in lp:~dawgfoto/duplicity/skip_sync_collection_status
- collection-status should not sync metadata
- up-to-date local metadata is not needed as collection-status is
generated from remote file list
- syncing metadata might require to download several GBs
