GNOME Bugzilla – Bug 768168
Copying/moving of native files is broken
Last modified: 2017-04-25 10:40:40 UTC
Created attachment 330529 [details] It explains google drive integration behavior I noticed I was unable to move a file located on root of google drive on nautilus, as the attached video explains, when I move a file to one of the folders, it looks like it's moving it so I click on the new icon at the top right of the titlebar to check the status of the operation but instead of displaying the name of the file appears "servicelogin", when done, a file with the name "edit" appears on the target folder but the original file remains on its original location...
I believe this is the google-drive support in gvfs, reassigning.
Moving/copying within google drive folder is not possible currently, see Bug 755701. I thought initially that this is duplicate of that bug, but not sure what is going on there after I've seen the video...
I've finally figured out that this happens only with native google drive documents, it happens also when copying those documents to local. Native files handling is a bit tricky. G_FILE_TYPE_SHORTCUT is used for them with link to Google Drive web, but link-type desktop file should be created while copying to local: /* While copying remote Drive content to local storage, we want to * create Link-type desktop files because GLocalFile doesn't know * about shortcuts. That might change in future. */ The problem is that Nautilus doesn't read content of the file, but reads the target-uri instead, which obviously doesn't work. So something changed in Nautilus, but still this is rather problem of GVfs...
Created attachment 330592 [details] [review] google: Use G_FILE_TYPE_REGULAR for native files G_FILE_TYPE_SHORTCUT is used currently for native Google Drive documents. GVfs provides fictive link-type desktop file content for them, however something was changed in Nautilus probably and it tries to read content of target uri instead of the content of the native file. Do not use G_FILE_TYPE_SHORTCUT file type and use G_FILE_TYPE_REGULAR instead in order to fix this issue. Rishi, what are you thinking about it?
Don't bother in fixing this, as comment 2 says moving/copying with google drive folder is not possible currently and it's better to wait until bug 755701 is fixed, in the event this bug needs to be fixed then it is ok to reopen it. Thank you for your attention.
Sorry, I forgot on this a bit, but as far as I know I didn't say it is better to wait until bug 755701 is fixed. Copy/move is not possible between two google drive locations, but it should work between local filesystem and google drive. This bug affects the latter case also (for native google drive files) and needs to be fixed regardless of bug 755701. I will ping Rishi about it...
(In reply to Ondrej Holy from comment #6) > Sorry, I forgot on this a bit, but as far as I know I didn't say it is > better to wait until bug 755701 is fixed. Copy/move is not possible between > two google drive locations, but it should work between local filesystem and > google drive. This bug affects the latter case also (for native google drive > files) and needs to be fixed regardless of bug 755701. I will ping Rishi > about it... Thank you for clarifying this, have a nice day.
Review of attachment 330592 [details] [review]: Thanks for all the investigation so far, Ondrej! The thing is that it works as expected when copy/pasting through other means than drag-and-drop. For example, when trying to copy within the Drive, the operation is failed (bug 755701), and when "downloading" to the local filesystem it is copied as a link. This is as expected. However, when DnDing, nautilus seems to use a different code path. It treats the Google Drive entry as a pure HTTP URI, which leads to this bug. I wonder why is that. Needs a closer look at the DnD code in nautilus and why it is different from other means of copying.
This behavior was introduced in 2013 to make sure that drag&drop works for some backends (i.e. recent, trash) also with applications which do not use GIO: https://git.gnome.org/browse/nautilus/commit/?id=1d1488cbc96ee9f7dd69b708e093d274a5374878 Then somebody realized that this is not a good idea for trash, because we should not access those files directly: https://bugzilla.gnome.org/show_bug.cgi?id=689248 G_FILE_TYPE_SHORTCUT is used in the following backends: afpbrowse, computer, dnssd, network, recent, smbbrowse, trash. But this behavior makes sense only for the recent backend, because GIO is needed in other cases (or it is not a good idea - i.e. trash). I see one possible use-case when this behavior makes sense also for google-drive. If you drag some native file and drop it in Firefox, you can see the file in your browser currently. However, I don't think that somebody uses this and it is more complicated than just clicking on the file. This obviously doesn't work with other than native files from google-drive. So, I would change the Nautilus behavior to use activation URI explicitly for the recent backend...
Created attachment 348641 [details] [review] file: Set activation URI for recent files only 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 commit 1d1488c. Recently, this behavior has been disabled for trash locations by commit bc22321. As far as I can tell, this behavior makes sense only for recent locations in order to allow dropping in applications, which are not based on GLib/GIO. Let's set the activation URI explicitly for recent locations only.
Review of attachment 348641 [details] [review]: I think this is needed also for a variety of cases, like the desktop links and G_FILE_TYPE_SHORTCUT types no? I actually think we would like to have the actual activation uri rather than the opposite for most of the cases. In this patch the code actually deactivates the target uri rather than Cosimo's patch which only changes dnd, so this affects much more cases. Cosimo I think I discussed this with you, do you have an opinion?
The activation uri for desktop links and symlinks is probably set at other places (nautilus-directory-async.c, nautilus-desktop-icon-file.c). This code is used only for G_FILE_ATTRIBUTE_STANDARD_TARGET_URI, which should be used only by G_FILE_TYPE_SHORTCUT/G_FILE_TYPE_MOUNTABLE and I think that those file types are provided by GVfs only. But you are right, this breaks opening shares from the network:// for example, hmm... I can create a patch fixing that only for google-drive, when d&d, but I think we should find some general solution. Handle each backend differently is a bit dumb...
Where is the activation URI used? Activation, mounting, drag&drop...? Activation URI is necessary for: afpbrowse, computer, dnssd, network, smbbrowse (especially for mounting, also d&d is needed for bookmarking) Just a note that those backends has also set G_FILE_ATTRIBUTE_STANDARD_IS_VIRTUAL to TRUE for all files (though not sure about the exact meaning of this flag, but it is probably used by GVfs only). It is useful for recent, because it contains links to local files ... It is not probably wanted for trash, because we should not access those files directly, but then it won't be possible to show the files from trash in non-GIO-based apps, hmm... For google, it is wanted for activation of native files, but not for d&d (it can be workaround by attachment 330592 [details] [review])... Activation uri is not used for nautilus links (I suppose it means symlinks and *.desktop links) when d&d since commit fa1211f8ed, so it should not affect something else. It would be nice to do the same for G_FILE_TYPE_IS_SHORTCUT, but it would break bookmarking of shares from network:/// etc. Maybe we can use activation uri for d&d for only G_FILE_ATTRIBUTE_STANDARD_IS_VIRTUAL files and recent files as an exception in order to fix this issue... What do you think?
I think that's the most sensible approach for now, yes. We have to revisit the activation URI thing anyway... we have been going back and forward on that, and it's still not clear to me.
Created attachment 350285 [details] [review] file: Set activation URI for certain files only 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 commit 1d1488c. Recently, this behavior has been disabled for trash locations by commit bc22321. 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 nautilus links (i.e. desktop files and symlinks), which are handled by different codepath, it should affect only certain GVfs backends.
Review of attachment 350285 [details] [review]: Maybe recent files should also use G_FILE_ATTRIBUTE_STANDARD_IS_VIRTUAL flag, because it isn't actually a real filesystem, but that's arguable...
Review of attachment 350285 [details] [review]: +1 thanks for looking into this! I agree recent should use virtual flag too (or something that relate all of these fake filesystems together) ::: src/nautilus-file.c @@ +2692,3 @@ if (!file->details->got_custom_activation_uri && + (g_file_info_get_attribute_boolean (info, G_FILE_ATTRIBUTE_STANDARD_IS_VIRTUAL) || + nautilus_file_is_in_recent (file))) missing one space in alignment (so it's clear is inside the &&)
Attachment 350285 [details] pushed as c6f6f07 - file: Set activation URI for certain files only Fixed the alignment.