Michael Terry has proposed merging
lp:~mterry/duplicity/giobackend-display-name-0.7 into lp:duplicity/0.7-series.
Requested reviews:
duplicity-team (duplicity-team)
For more details, see:
https://code.launchpad.net/~mterry/duplicity/giobackend-display-name-0.7/+merge/328633
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/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: 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.
--
Your team duplicity-team is requested to review the proposed merge of
lp:~mterry/duplicity/giobackend-display-name-0.7 into lp:duplicity/0.7-series.
=== modified file 'duplicity/backends/giobackend.py'
--- duplicity/backends/giobackend.py 2016-01-29 11:43:58 +
+++ duplicity/backends/giobackend.py 2017-08-05 22:24:42 +
@@ -116,8 +116,11 @@
def __copy_file(self, source, target):
from gi.repository import Gio # @UnresolvedImport
+# Don't pass NOFOLLOW_SYMLINKS here. Some backends (e.g. google-drive:)
+# use symlinks internally for all files. In the normal course of
+# events, we never deal with symlinks anyway, just tarballs.
source.copy(target,
-Gio.FileCopyFlags.OVERWRITE | Gio.FileCopyFlags.NOFOLLOW_SYMLINKS,
+Gio.FileCopyFlags.OVERWRITE,
None, self.__copy_progress, None)
def _error_code(self, operation, e):
@@ -150,12 +153,18 @@
def _list(self):
from gi.repository import Gio # @UnresolvedImport
files = []
-enum = self.remote_file.enumerate_children(Gio.FILE_ATTRIBUTE_STANDARD_NAME,
- Gio.FileQueryInfoFlags.NOFOLLOW_SYMLINKS,
+# We grab display name, rather than file name because some backends
+# (e.g. google-drive:) use filesystem-specific IDs as file names and
+# only expose the "normal" name as display names. We need the display
+# name, because we try to parse them. If the backend does this sort of
+# trickery, it will accept both versions of the filename, so we
+# shouldn't get into any trouble doing this.
+enum = self.remote_file.enumerate_children(Gio.FILE_ATTRIBUTE_STANDARD_DISPLAY_NAME,
+ Gio.FileQueryInfoFlags.NONE,
None)
info = enum.next_file(None)
while info:
-files.append(info.get_name())
+files.append(info.get_display_name())
info = enum.next_file(None)
return files
___
Mailing list: https://launchpad.net/~duplicity-team
Post to : duplicity-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~duplicity-team
More help : https://help.launchpad.net/ListHelp
