Merge lp:~mterry/duplicity/giobackend-display-name into lp:~duplicity-team/duplicity/0.8-series
Status: | Merged |
---|---|
Merged at revision: | 1253 |
Proposed branch: | lp:~mterry/duplicity/giobackend-display-name |
Merge into: | lp:~duplicity-team/duplicity/0.8-series |
Diff against target: |
37 lines (+13/-4) 1 file modified
duplicity/backends/giobackend.py (+13/-4) |
To merge this branch: | bzr merge lp:~mterry/duplicity/giobackend-display-name |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
duplicity-team | Pending | ||
Review via email: mp+328631@code.launchpad.net |
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 the google-drive: GIO 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: GIO 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.