Let several file operations work on Google Drive #1598
Conversation
besser82
changed the title
|
thanks, I saw many bug reports about bug/s with rename, hope that this solves them or at least part of them (about "file: Let renames work on Google Drive" commit) @besser82 add also the change of debian/control "libglib2.0-dev (>= 2.37.3)," to "libglib2.0-dev (>= 2.45.7)," now missed |
|
@Fantu All the commits in this PR will solve most of the issues with gDrive (and maybe other GVFS clients). |
besser82
force-pushed
the
bugfix/gvfs
branch
from
f2ad4a5
to
f9423d1
Compare
Renaming an item on Google Drive does not change the actual GVfs path because the path is made up of document-ids, which do not change. A rename operation only affects the title of the entry. In GIO terms, only the standard::display-name changes, but the standard::name remains the same. Therefore, if there is already a file with the same standard::name, then don't mark it as gone if it is the same file that we are renaming. https://bugzilla.gnome.org/show_bug.cgi?id=740383
We really should be using standard::display-name when renaming files - g_file_get_basename is simply not the right thing to use. Moreover, in case of Google Drive, the URI might not change with the display name and we can not get the old display name from the old GFile. Therefore, let's explicitly keep track of the old and new display names to address these issues. https://bugzilla.gnome.org/show_bug.cgi?id=754785
Immediately check the volatility of the newly created file or directory and switch to using the "real" persistent URI. The following operations are affected: - creating new directories - creating new files from templates - dragging & dropping text to create new files - copying and moving of files and directories The Google Drive backend doesn't support creating symbolic links so we ignore that case. https://bugzilla.gnome.org/show_bug.cgi?id=751481
Drag&drop of native Google Drive files doesn't work correctly, because target path is used, which causes requests for HTTP backend and fails. The activation URI is used for drag&drop since some time ago. Recently, this behavior has been disabled for trash locations. This behavior seems to make sense for recent locations in order to allow dropping in applications, which are not based on GLib/GIO. It also makes sense for afpbrowse, dnssd, network, and smbbrowse backends when mounting and bookmarking. Let's set the activation URI only for the mentioned. This change should not affect Nemo links (i.e. desktop files and symlinks), which are handled by different codepath, it should affect only certain GVfs backends. https://bugzilla.gnome.org/show_bug.cgi?id=768168
besser82
force-pushed
the
bugfix/gvfs
branch
from
a16d302
to
163feb4
Compare
|
I can confirm this fixes being able to undo rename operations. However I'm seeing a regression on text files... before this PR double-clicking a text file in a Google Drive mount opened it up in Firefox... now, Cinnamon is unable to detect how to open it and asks the user to choose a program for it. |
|
The regression seems to come from "file: Set activation URI for certain files only". |
|
@besser82 I'm unable to test creating new files.. it fails both on master and with this PR. I would suggest to split the PR so we can merge the functional bits (rename operations, dependencies), and create different PRs for creations and activation URIs so they can be tested and merged in isolation. |
|
How does one get gdrive working here? I've setup my account in the new Online Accounts settings. Is there an accepted/standard way to get drive to show up on gvfs after this? |
|
@mtwebster is gvfs-goa installed? After setting up in settings it should appear in nemo under network. |
|
rename, undo and glib-dep commits merged. |
Several fixes for using gDrive with GVFS with Nemo. Backported from GNOME Nautilus.