GNOME Bugzilla – Bug 586367
In local_only mode, file chooser should return native paths for files in FUSE mounts.
Last modified: 2013-05-29 07:41:47 UTC
Please describe the problem: Hi, I can't access network shares by using the open/save file dialog, e.g. in Thunderbird when trying to add an attachment. And even if I try to add it by drag&drop which seems to work in general it can't send the mail because it doesn't seem to be able to resolve the address "smb://" Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Other information:
I want to add that I am using Ubuntu 9.04 and I have installed the thunderbird-gnome-support package. Furthermore, I want to add that I mean that you don't have the Network-Option available itself (nor can you access it by using smb://) also in OpenOffice for instance. Only already mounted drives are displayed there (Thunderbird and Firefox this works not even after they are mounted). I think the general network option should be displayed/usable as well.
The way this works is that you can mount a network location, e.g. and ftp server, and then the volume _will_ show up in the places list in the file chooser. Or, you can add bookmarks to network locations, and then the location will be mounted when you click on the bookmark in the file chooser.
As said: Even if it is already mounted I can't get Thunderbird or Firefox to access those places. Even with the according "AddOns" installed (as I mentioned in Comment#1. And also I don't completely see the reason for not adding (or actually removing?) the Network place there (as it exists in normal Nautilus) Furthermore, I actually would like to see Save-As and Open-File-Dialogs to behave more like normal Nautilus because of possibilities like change to Icon-View or renaming already existing files and folder (I actually used that possibility a lot under Windows, especially because it allowed also to copy folder names and name the file you were going to save accordingly).
I don't think this is a gtk+ bug; xulrunner applications (firefox, thunderbird, ...) simply don't use GIO, so they're limited to local files.
Andreas, does this work for example in Gedit? If so, it's not a GNOME bug.
On my Ubuntu Jaunty (gedit 2.26.1) the "Open files" dialog has no "Network" option. However if I navigate to a share via Nautilus *and then* try to open the file in gedit, the share appears in the places list. Firefox instead stays network-unaware all the time.
With the switch from gnome-vfs to gio, we lost the "network:///" link on what GtkFileSystem returns. You need to look at gtkfilesystem.c:get_volumes_list() and put the network:/// link there. You may want to look at the old libgnomeui/file-chooser/gtkfilesystemgnomevfs.c to see how it uses an opaque token to simulate a Network volume. This code existed around the branch for GNOME 2.22.
This seems to be working in GTK3, but as apps like thunderbird and firefox still use GTK2 where it doesn't seem to be fixed. Would be good to get the fix back ported anyone got any idea what the fix was here?
In gtkfilesystem.c, get_volumes_list() is the internal function that fills priv->volumes with the list of volumes to show. In the gtk-2-24 branch, all that function does is: 1. list the volumes belonging to drives 2. list the volumes not belonging to drives 3. list the mounts Somewhere there it also needs to create a fake "volume" for the network:/// URI. I say a fake "volume" because what _gtk_file_system_list_volumes() returns is a list of GtkFileSystemVolume, which is an opaque pointer. Internally, GtkFileSystem can have those things be GVolume objects or other things. For example, you'll see that _gtk_file_system_list_volumes() has this bit: #ifndef G_OS_WIN32 /* Prepend root volume */ list = g_slist_prepend (list, (gpointer) root_volume_token); #endif And root_volume_token is just this (from the beginning of the file): /* The pointers we return for a GtkFileSystemVolume are opaque tokens; they are * really pointers to GDrive, GVolume or GMount objects. We need an extra * token for the fake "File System" volume. So, we'll return a pointer to * this particular string. */ static const gchar *root_volume_token = N_("File System"); #define IS_ROOT_VOLUME(volume) ((gpointer) (volume) == (gpointer) root_volume_token) I.e. the returned list of "volumes" in reality has things like GDrive, GVolume, GMount, pointer-to-unique-string which are presented to the outside as an opaque GtkFileSystemVolume. To add the network:/// URI, you can simply define something like static const gchar *network_volume_token = "network:///"; and add it to the returned list in a similar fashion to the root_volume_token. Then you need to modify _gtk_file_system_volume_*() to take that new token into account - to get the display name ("Network Servers"), the base URI ("network:///"), etc. We did exactly this in the implementatin of GtkFileSystem that used gnome-vfs internally; it's unfortunate that we lost that bit when everything got ported to GIO. You can see the old gnome-vfs based code here: http://git.gnome.org/browse/libgnomeui/tree/file-chooser/gtkfilesystemgnomevfs.c?h=gnome-2-20 (grep for "network_servers_volume_token" - it's the same idea). If you write a patch to implement this, I'll gladly review it and include it in the gtk-2-24 branch. HOWEVER: This does not mean that Firefox et al will automatically get a network:/// item! Applications *have* to do gtk_file_chooser_set_local_only(chooser, FALSE) in order to get arbitrary URIs, not just Unix-native file:/// ones. I really don't know if Firefox would know what to do with a "smb:///" URI, for example.
Thanks for the reply Federico. "Applications *have* to do gtk_file_chooser_set_local_only(chooser, FALSE)" This is very interesting after comparing the code in get_volumes_list() between gtk2/3 it appears that the are pretty much identical. It mostly consists of glib calls. I'm going to write a small gtk2 test app but at this stage I'm starting to think there is not problem with the library and this is indeed an application bug. This seems to be supported by some comments in a firefox bug I dug up: https://bugzilla.mozilla.org/show_bug.cgi?id=526293#c2
Created attachment 229113 [details] GTK2 file chooser test app This test app confirms that there is no longer issues with network mounts not appearing in the shortcuts in GTK2, my guess is this was fixed in GLIB. To compile: g++ gtk_file_chooser_test_gtk2.c -o simple-gtk `pkg-config gtk+-2.0 --cflags --libs` I have only tested this with afp:// so maybe some else should confirm other protocols but I think its safe to make this as an application issue rather that a GTK one.
One further thing I've noticed from my test app is that the file chooser is not returning a uri to the network location directly e.g afi:///blah or smb:///blah Instead its returning something like this: /run/user/timothy/gvfs/afp-volume:host=DiskStation.local,user=admin,volume=Videos/Untitled Document 1.txt This is all getting a little beyond my knowledge here but what seems to be happening is this can be used with the file protocol and gvfs will do some magic and provide the application with access to the location without need to handle the network protocols in the application itself. If this is the case would it be safe to have local_only set to FALSE by default?? Or I'm I missing something? Note: I'm building firefox with local_only set to false for further testing but if I use file:///run/user/timothy/gvfs/afp-volume:host=DiskStation.local,user=admin,volume=Videos/Untitled Document 1.txt directly in the address bar it can open the file. Also if I open a video file via Nautilus in VLC it Nautilus passes the same type of address to VLC and again it works.
Just to be sure I tested another protocol. I tested ftp. If I mount the public mozilla ftp ftp.mozilla.org/pub file chooser returns: file:///run/user/timothy/gvfs/ftp:host=ftp.mozilla.org,user=anonymous/pub/README when I select the README file.
Created attachment 229211 [details] [review] Show FUSE locations The attached patch allows FUSE locations to be added to shortcuts regardless of whether gtk_file_chooser_set_local_only() is set to TRUE. Since FUSE locations can be handled safely by applications we should show these locations regardless. I've also updated the gtk_file_chooser_set_local_only() documentation to reflect this change.
Sorry, I have missed a couple of things with this patch and have a follow up in progress.
Created attachment 229228 [details] [review] Show FUSE locations v2 This patch works much better I can use the file chooser to open files at FUSE locations, however saves to FUSE locations don't seem to work
Created attachment 229230 [details] [review] Show FUSE locations v3 Fixed typo in last patch
Created attachment 229270 [details] [review] Show FUSE locations v4 This patch seems to enable all thats needed on the frontend to return the local gvfs location for both saving and opening. There are some warnings being thrown on my gtk+2 testing (I'm yet to test on GTK3): (simple-gtk:19889): Gtk-WARNING **: Operation not supported by backend (simple-gtk:19889): Gtk-WARNING **: Operation not supported by backend And although its returning the full address Firefox is not acctually saving anything to the location returned. I think I'm missing something.
Created attachment 229279 [details] [review] Show FUSE locations v5 It turned out that Firefox was calling gtk_file_chooser_get_uri() rather than gtk_file_chooser_get_filename () This updated patch handles calls to gtk_file_chooser_get_uri() for FUSE locations.
Bump. Although a did have a frequent succession of patch there for a while I'm pretty happy with the state of the latest patch. And I'm open to comments from the devs? Also if this patch is accepted for GTK+3 I'll happily provide the GTK+2 equivalent which I have also successfully tested. Please also note the warnings from my previous post only appear with GTK+2, however they don't seem to cause any actual issues.
Created attachment 235463 [details] [review] Show FUSE locations v6 Updated boolean variable name as the old name didnt make sense
Last request for a review before I give up. I can only ask via, bugzilla, irc and email so many times.
Ack, *hangs head in shame*. I'm integrating your patch right now. A few things: * Good catch on making g_file_get_path() be the "do you have a native-filesystem representation" function! I wasn't aware that it could be used that way. * I'll change your _gtk_file_is_path_not_local() to be named something like _gtk_file_has_filesystem_representation(). I don't like negatives in the names of boolean functions :) Many apologies for the ultra-late patch review; with all the work you have put into this, I should have been more diligent.
> * Good catch on making g_file_get_path() be the "do you have a > native-filesystem representation" function! I wasn't aware that it could be > used that way. When looking into how Nautilus handled FUSE locations I tracked it all the way back to GLib using g_file_get_path() in this way so it should be safe to do so. > Many apologies for the ultra-late patch review; with all the work you have put > into this, I should have been more diligent. I understand that you guys as busy but there must be a better way to handle patch reviews so they dont get forgotten about. Currently GTK has 677 patches marked unreviewed. It's unfortunate that this is the case, I've submitted a number of patches over the past year or so and I've spent on average the same amount of time following up on reviews (and then asking for commits) then I have making code changes. I would have worked on more bugs but I was of the view that it was better to make sure the patches I had submitted were looked at first. So for now I'm moving on from GTK development as life to short. Can I just ask you to do one more thing before I move on and thats replace the git branch: https://git.gnome.org/browse/gtk+/log/?h=bgo121113-filechooser-single-click-activate With an updated one that contains my patch to work with GTK+3 and use GSettings. See: https://bugzilla.gnome.org/show_bug.cgi?id=121113
(In reply to comment #24) > When looking into how Nautilus handled FUSE locations I tracked it all the way > back to GLib using g_file_get_path() in this way so it should be safe to do so. Yes, this is completely right. Thanks for figuring it out. I've pushed your changes to master, with some modifications: * Renamed _gtk_file_is_path_not_local() to _gtk_file_has_native_path() and fixed the corresponding logic, to avoid having negatives in the name of functions that return a boolean. * Fixed use of g_file_is_native(), to use _gtk_file_has_native_path() in conjunction with local_only throughout. * Fixed gtk_file_chooser_get_uris(), as that one was not doing the conversion to a native path. The commits in question are cf216d780..a89d42027 inclusive. I'll backport them to gtk-2-24. > Can I just ask you to do one more thing before I move on and thats replace the > git branch: > https://git.gnome.org/browse/gtk+/log/?h=bgo121113-filechooser-single-click-activate > With an updated one that contains my patch to work with GTK+3 and use > GSettings. > See: https://bugzilla.gnome.org/show_bug.cgi?id=121113 Done. I split the patch into three commits as in the original version. Keeping this bug open until I backport the patches to gtk-2-24.
Thanks, Federico. Its great to see this will make it into the next release of GTK+ I know this will be a simple but big improvement to a lot of people.
Pushed to gtk-2-24 in commits 5d32c055 through 3c993547.
*** Bug 676122 has been marked as a duplicate of this bug. ***
*** Bug 531098 has been marked as a duplicate of this bug. ***