Merge lp:~mterry/duplicity/giobackend-display-name into lp:~duplicity-team/duplicity/0.8-series

Proposed by Michael Terry
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
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/user-visible name that we want to work with anyway.

(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.

To post a comment you must log in.

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== modified file 'duplicity/backends/giobackend.py'
2--- duplicity/backends/giobackend.py 2017-02-20 00:05:17 +0000
3+++ duplicity/backends/giobackend.py 2017-08-05 21:47:05 +0000
4@@ -116,8 +116,11 @@
5
6 def __copy_file(self, source, target):
7 from gi.repository import Gio # @UnresolvedImport
8+ # Don't pass NOFOLLOW_SYMLINKS here. Some backends (e.g. google-drive:)
9+ # use symlinks internally for all files. In the normal course of
10+ # events, we never deal with symlinks anyway, just tarballs.
11 source.copy(target,
12- Gio.FileCopyFlags.OVERWRITE | Gio.FileCopyFlags.NOFOLLOW_SYMLINKS,
13+ Gio.FileCopyFlags.OVERWRITE,
14 None, self.__copy_progress, None)
15
16 def _error_code(self, operation, e):
17@@ -150,12 +153,18 @@
18 def _list(self):
19 from gi.repository import Gio # @UnresolvedImport
20 files = []
21- enum = self.remote_file.enumerate_children(Gio.FILE_ATTRIBUTE_STANDARD_NAME,
22- Gio.FileQueryInfoFlags.NOFOLLOW_SYMLINKS,
23+ # We grab display name, rather than file name because some backends
24+ # (e.g. google-drive:) use filesystem-specific IDs as file names and
25+ # only expose the "normal" name as display names. We need the display
26+ # name, because we try to parse them. If the backend does this sort of
27+ # trickery, it will accept both versions of the filename, so we
28+ # shouldn't get into any trouble doing this.
29+ enum = self.remote_file.enumerate_children(Gio.FILE_ATTRIBUTE_STANDARD_DISPLAY_NAME,
30+ Gio.FileQueryInfoFlags.NONE,
31 None)
32 info = enum.next_file(None)
33 while info:
34- files.append(info.get_name())
35+ files.append(info.get_display_name())
36 info = enum.next_file(None)
37 return files
38

Subscribers

People subscribed via source and target branches