After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 528670 - Always pass file:/// uri's in GAppLaunchContext
Always pass file:/// uri's in GAppLaunchContext
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: gio
unspecified
Other Linux
: Normal normal
: ---
Assigned To: David Zeuthen (not reading bugmail)
gtkdev
: 551575 (view as bug list)
Depends on: 530654
Blocks:
 
 
Reported: 2008-04-18 00:26 UTC by David Zeuthen (not reading bugmail)
Modified: 2009-10-30 14:30 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Proposed patch (3.35 KB, patch)
2008-04-18 00:31 UTC, David Zeuthen (not reading bugmail)
none Details | Review
Updated patch (2.62 KB, patch)
2008-04-30 00:13 UTC, David Zeuthen (not reading bugmail)
committed Details | Review

Description David Zeuthen (not reading bugmail) 2008-04-18 00:26:47 UTC
This bug was originally filed in the Red Hat bugzilla 

 https://bugzilla.redhat.com/show_bug.cgi?id=442835

Lots of desktop files use '%u' to specify that they want a URI rather than an old skool POSIX file path. Unfortunately %u is way too optimistic as

 - there are many different URI schemes (one for each VFS system) and there
   is little or no standardization (e.g. ssh:// for gvfs, fish:// for KDE)

 - Many applications are overly optimistic and set %u even though they'll
   never ever support anything but files

 - lots of GNOME apps still use gnome-vfs and as such don't support newer
   URI's from gio (gphoto2, cdda). And even for the ones they do support,
   for example ssh://, it may mean asking for credentials again

The current situation is clearly suboptimal: right now you can't even open text files (gedit) or view images (eog) from URI's not supported by gnome-vfs. This includes archive://, gphoto2:// and cdda://. This is not ideal.

Fortunately gvfs supports a FUSE mount at ~/.gvfs. In fact, if a desktop file uses %f instead of %u, then a path into ~/.gvfs will be used instead. The application will Just Work(tm).

Will attach a patch that will pass a POSIX FUSE path instead of an URI for %u and %U if both of the following conditions are met

 - the desktop file doesn't have a key X-Gnome-Vfs-System with the value gio
 - FUSE is available and mounted at e.g. $HOME/.gvfs

As such, the thinking is that apps that use gio will have

 X-Gnome-Vfs-System=gio

in their desktop files. With this patch using things like gedit, eog and mplayer (and virtually any other non-gio app) from the Nautilus Just Works(tm). It's pretty cool actually.

It's probably worth raising the larger problem at xdg-list and settle on a key similar in spirit to X-Gnome-Vfs-System.

FWIW, we're going to try and ship this patch for Fedora 9.
Comment 1 David Zeuthen (not reading bugmail) 2008-04-18 00:31:14 UTC
Created attachment 109462 [details] [review]
Proposed patch
Comment 2 Behdad Esfahbod 2008-04-18 01:57:55 UTC
Can you raise on xdg-list and quickly agree on a non-GNOME-specific key?
Comment 3 David Zeuthen (not reading bugmail) 2008-04-18 02:05:20 UTC
(In reply to comment #2)
> Can you raise on xdg-list and quickly agree on a non-GNOME-specific key?

It might be better to first agree whether we want this in gio in the first place. FWIW, I *think* we do as mclasen and I decided to try this for F9. We'll see.
Comment 4 Dan Winship 2008-04-18 12:46:22 UTC
If you do keep the GNOME-specific key, it should be "X-GNOME-", not "X-Gnome-", to be consistent with other GNOME-specific keys.
Comment 5 David Zeuthen (not reading bugmail) 2008-04-22 16:21:25 UTC
A better is this

 - Always pass FUSE paths even to gio apps (if the FUSE daemon is available).
   That way we won't need a X-Gnome-Vfs-System desktop key.

 - Have the fuse daemon set an xattr on every mount with the gio URI, e.g.
   the directory "$HOME/.gvfs/gphoto2 mount on usb:001,042" would have
   an xattr called gio:uri with the value gphoto2://[usb:001,042]/

 - All GFile constructors would check, for file:/// URI's, if the path
   is into the FUSE mount, e.g. begins with $HOME/.gvfs

   - If so, lookup the gio:uri xattr and convert the uri to the
     use this. E.g. this piece of code

      GFile *f;
      f =  g_file_new_for_command_line_arg (
             "/home/davidz/.gvfs/gphoto2 mount on usb:001,042/foo.txt"
      g_print ("uri=%s\n", g_file_get_uri (f));

     would print

      uri=gphoto2://[usb:001,042]/foo.txt

     Ditto for g_file_new_from_path(), g_file_new_from_commandline_arg()
     and g_file_parse_name().
  
   - The CPU overhead in checking the given uri / path / command line arg
     points into the fuse mount is virtually nil compared to the overhead of 
     constructing the GFile object itself

   - This does a minimal amount of IO [1], e.g. looking up the xattr on
     the fuse, only if the passed uri actually points into the FUSE mount

     - this is OK since properly written apps would only every encounter
       FUSE paths when taking incoming data from other apps (e.g. command
       line arguments). 

     - Since we convert early and in every GFile constructor the app
       would quickly end up using real URI's instead of FUSE paths. E.g.
       this piece of code doing IO would very rarely run; basically only
       when the app starts and process the uri's given on the command line.

I will look into writing patches for this.

[1] : alexl's stance is that we cannot do any IO at all 
Comment 6 Alexander Larsson 2008-04-29 19:20:06 UTC
Some comments:

Not all uris are availible via fuse, even if fuse is active
Only "visible" mounts are shown in fuse, which means things
like network: computer: etc don't work. Also, http doesn't work. Any implementation needs to actually try to convert the arguments to local paths to make sure it works before falling back.

You can't always roundtrip a uri through a GFile and expect things 
to always works. Many uris are not for "files" and the uri parser in GIO 
just won't understand them. Take for instance mailto: uris or callto: uris.

In many cases you really want the actual uri in the app, not the fuse path, passing a fuse path to something like wget or mozilla just doesn't make any sense as they generally do more with the uri than just open a file. 
Comment 7 David Zeuthen (not reading bugmail) 2008-04-29 19:42:22 UTC
Hey Alex,

Thanks for taking some time to comment on this. I appreciate it.

(In reply to comment #6)
> Some comments:
> 
> Not all uris are availible via fuse, even if fuse is active
>
> Only "visible" mounts are shown in fuse, which means things
> like network: computer: etc don't work. Also, http doesn't work. Any
> implementation needs to actually try to convert the arguments to local paths to
> make sure it works before falling back.
> 
> You can't always roundtrip a uri through a GFile and expect things 
> to always works. Many uris are not for "files" and the uri parser in GIO 
> just won't understand them. Take for instance mailto: uris or callto: uris.

In the case of 1) either FUSE not available; or 2) mount not available via FUSE; then g_file_get_path() will return NULL. In that case the patch in comment 1 actually falls back and tries just to pass the proper URI just like we do today. (In fact, the check for http in that patch is superfluous) 

Which I think addresses your concerns, right?

> In many cases you really want the actual uri in the app, not the fuse path,
> passing a fuse path to something like wget or mozilla just doesn't make any
> sense as they generally do more with the uri than just open a file. 

Right, that's what I proposed in comment 5 by tweaking the GFile constructors to map URI's of the form file://$HOME/.gvfs back to URI's by looking at base URI from xattrs on the directories of the root of the fuse mount. 

Do you see any problems with this approach?

Anyway, I'll try to whip up gvfs and gio patches based on comment 5 tonight. I wanted to do that last week, but I got carried away with other things.
Comment 8 Bastien Nocera 2008-04-29 22:46:38 UTC
Note that it also causes problems with:
- applications that don't use GIO but support URIs (say, a web browser, or a movie player)
- applications that map back between specific URIs and devices (sound-juicer, totem and rhythmbox need to be able to map back between cdda://sr0/ and /dev/sr0, but might not use GIO).

I'd rather applications be encouraged to use gio directly. Even for an application that doesn't fully use gio, patching it to give a try opening the local FUSE path is 3 lines of code.
Comment 9 David Zeuthen (not reading bugmail) 2008-04-29 23:19:09 UTC
(In reply to comment #8)
> Note that it also causes problems with:
> - applications that don't use GIO but support URIs (say, a web browser, or a
> movie player)

Do you have any concrete examples here? It's not like mailto:// or http:// or asf:// paths will be replaced by a FUSE path. They can't, because there's no mount. So the URI will be passed.

> - applications that map back between specific URIs and devices (sound-juicer,
> totem and rhythmbox need to be able to map back between cdda://sr0/ and
> /dev/sr0, but might not use GIO).

FWIW, cdda:// in gvfs will be renamed to cdafs://, see bug 527159. We should try hard to make sure there is no overlap between the gstreamer and the gvfs URI schemes to avoid to these kind of problems. 

> I'd rather applications be encouraged to use gio directly. 

(Except when it comes to using the gvfs cdda backend?)

> Even for an
> application that doesn't fully use gio, patching it to give a try opening the
> local FUSE path is 3 lines of code.

Speaking of three, or maybe four, lines of code; I think, for s-j, totem, rhythmbox it's just as easy to do

 GFile *f = g_file_new_for_commandline_arg (argv[0]);
 char *uri = g_file_get_uri (f);
 if (g_str_has_prefix (uri, "cdafs://")) {
   /* compute your gstreamer uri here */
 }

if you really insist on making these apps bypass gvfs for playback / extracting audio from Audio CD's.

Here's the thing: lots of apps will never ever move to gio, e.g. mplayer, KDE apps and so forth. And these apps will _continue_ to use the ill-defined %u parameter in their desktop files. This results in breakage en masse when launching files from Nautilus. The problem is that %u simply doesn't work when you have more than one VFS system. IMO it was a mistake to introduce it in the desktop entry spec.
Comment 10 David Zeuthen (not reading bugmail) 2008-04-30 00:13:27 UTC
Created attachment 110138 [details] [review]
Updated patch

Here's an updated patch
Comment 11 David Zeuthen (not reading bugmail) 2008-04-30 00:14:31 UTC
For the required gvfs patch to fixup the GFile constructors to map back (actually there was even a TODO in the source to do this), see bug 530654.
Comment 12 Benjamin Otte (Company) 2008-05-22 09:03:19 UTC
(In reply to comment #8)
> Note that it also causes problems with:
> - applications that don't use GIO but support URIs (say, a web browser, or a
> movie player)
>
There is a huge problem with mapping "URIs" between different applications. I am very sure that gvfs, gstreamer and your web browser have very different ideas about what a URI is[1]. The only thing they unfortunately agree on is the syntax, which means it's impossible to tell different VFSs apart.

I think the first step to get back to sanity would be changing GIO to not report ftp:// or http:// URLS but instead use gvfs://<mount>/<path> syntax. That would at least avoid confusion about what an ftp:// URL is. Plus, it would be exceptionally easy to s.gvfs://./home/me/.gvfs. or vice versa to convert to local paths. And this is the point where you could just use local paths anyway and avoid lots of pain if you made the FUSE daemon mandatory.


[1]: Example: GVfs paths are by design absolute and they start at a designated root directory. These are two assumptions that don't hold for the RFC specifying the ftp:// URI scheme. [2] So it is not possible by design to map your browser's idea of ftp to GVfs. I'm not sure what epiphany ftp://user@example.com should display?

[2]: ftp://ftp.isi.edu/in-notes/rfc1738.txt - paragraph 3.2
Comment 13 David Zeuthen (not reading bugmail) 2008-09-09 21:09:20 UTC
*** Bug 551575 has been marked as a duplicate of this bug. ***
Comment 14 Gavin Hamill 2008-09-09 21:20:32 UTC
Am sad to see this interesting discussion has stalled. 

It's certainly a nontrivial task, but a partial solution that works adequately for 80% of cases [1] would certainly be an improvement over confusing 'does nothing' operation which currently reigns.

[1] I'm thinking mainly of smb:// or sftp:// URIs - likely candidates for remote volumes within Nautilus on which you'd want a local app to act.
Comment 15 David Zeuthen (not reading bugmail) 2008-09-26 16:50:44 UTC
We're getting closer - Alex committed the patch in bug 530654.

See bug 530654 comment 6 for some thoughts on how to resolve this bug without having to include hints in the desktop file.
Comment 16 David Zeuthen (not reading bugmail) 2008-09-26 16:55:48 UTC
Fixing up summary. Also, the patch in comment 10 pretty much should work even though it may have bitrotted.
Comment 17 Matthias Clasen 2008-09-29 14:05:59 UTC
So, if we were to put this in glib 2.18.x, how badly will it break 

a) with a gvfs that doesn't have the fix in bug 530654 ?

and

b) will it break apps that expect real urls unless they do what David described in comment #9 ?

 GFile *f = g_file_new_for_commandline_arg (argv[0]);
 char *uri = g_file_get_uri (f);
 if (g_str_has_prefix (uri, "cdafs://")) {
   /* compute your gstreamer uri here */
 }



Comment 18 David Zeuthen (not reading bugmail) 2008-09-29 14:34:35 UTC
(In reply to comment #17)
> So, if we were to put this in glib 2.18.x, how badly will it break 
> 
> a) with a gvfs that doesn't have the fix in bug 530654 ?

Apps, even with using gio, will do IO through the fuse daemon; it's what we're doing in F9 (try opening a movie through a sftp url), seems to work fine. There's a performance penalty though.

> b) will it break apps that expect real urls unless they do what David described
> in comment #9 ?
> 
>  GFile *f = g_file_new_for_commandline_arg (argv[0]);
>  char *uri = g_file_get_uri (f);
>  if (g_str_has_prefix (uri, "cdafs://")) {
>    /* compute your gstreamer uri here */
>  }

For the cdda:// example it means totem will get a file:/// fuse uri; it will playback the file just fine. Though certain metadata might be missing that totem would have been able to obtain using the gstreamer cdda plug-in.

Anyway, I still maintain that apps that break in this case (expecting a special uri to be passed to them and breaking when getting a file:/// fuse uri) are broken anyway. They're relying on non-specified [1] magic uri formats.

Actually I'm not sure we want this for glib 2.18 / gvfs in 2.24; there's always interesting distro-specific stuff that might show up. So here's what I'd suggest going forward

 - apply the patch in comment 10 to trunk; then, assuming we get a new glib
   release for GNOME 2.26, then GNOME 2.26 will be fine and all this will
   work. Any bugs (which will typically be application bugs) that might show
   up can also get fixed during the 2.25 cycle.

 - tell vendors they need to patch gio (with the patch in comment 10) and
   gvfs (with the patch from bug 530654) if they want this functionality.
   The fact that a similar approach has caused no problems in Fedora 9 might
   help convince people it's fine.

   Specifically for Fedora 10, I would recommend that (just a continuation
   from what we've been doing in Fedora 9).

Thoughts?

[1] : non-specified in the sense that, for a given uri scheme foo, there's a) no specification for the foo uri format; and b) no specification of how to share authentication / session / cookies. See bug 530654 comment 8 paragraphs 2 + 3 for more details.
Comment 19 Gavin Hamill 2008-09-29 18:35:30 UTC
I'm not sure what negative impact applying this to stable could have.  There's a gut-feeling of 'this is changing too much behaviour for stable' but thinking it through rationally, it's not going to be breaking anything.

Far from it, it will be transparently enhancing the scope of GNOME for a negligible penalty (some apps will show 'file://' URIs instead of proto://' ones)

definitely +1 on "mplayer et al are broken already by implementing their own proto://" - the scope of launching mplayer from Nautilus is surely negligible anyway. 
Comment 20 Benjamin Otte (Company) 2008-09-29 18:48:13 UTC
GNOME needs a policy about stable releases and what kind of stuff is allowed to be put into them.
I have the same gut feeling about breaking stuff and would think it should only be applied to 2.26. Or would any of you ship this in a RHEL update?
Comment 21 David Zeuthen (not reading bugmail) 2008-10-01 16:02:01 UTC
any chance we can commit the patch in comment 10 on trunk?
Comment 22 Matthias Clasen 2008-10-01 16:05:10 UTC
Yes, committing this to trunk is fine. 

Can you also add a paragraph (and a "Notes about GLib 2.20" section) to README.in
with some of the hints from comment #9 ?
Comment 23 David Zeuthen (not reading bugmail) 2008-10-01 17:48:47 UTC
Committed with some docs/notes added

 http://svn.gnome.org/viewvc/glib/trunk/README.in?r1=6947&r2=7566&view=patch
 http://svn.gnome.org/viewvc/glib/trunk/gio/gappinfo.c?r1=7554&r2=7566&view=patch

2008-10-01  David Zeuthen  <davidz@redhat.com>

	* gdesktopappinfo.c (expand_macro): If possible, always pass FUSE
	file:// URIs (such as '/home/davidz/.gvfs/sftp on foo/file.avi')
	instead of the gio URI (such as sftp://foo/file.avi) when using
	g_app_info_launch() and friends. With a sufficiently recent gvfs,
	apps using gio+gvfs will map the FUSE file:// URI back to the gio
	URI (and thus bypass the fuse daemon) thanks the patch from bug
	#530654.  Since Nautilus is an user of g_app_info_launch() it
	means that non-gio POSIX apps, such as mplayer, will Just Work(tm)
	when launced via the file manager. Win. Fixes bug #528670.

	* gappinfo.c: Add some notes about the FUSE POSIX URI <-> GIO URI
	mapping to the description of GAppInfo.

2008-10-01  David Zeuthen  <davidz@redhat.com>

	* README.in: Add "Notes about glib 2.20" section detailing the
	ramifications of the patch from bug #528670.
Comment 24 Vlad C. 2008-10-03 04:51:19 UTC
(In reply to comment #5)

 - All GFile constructors would check, for file:/// URI's, if the path
   is into the FUSE mount, e.g. begins with $HOME/.gvfs


I think this condition is a little too strict because a file may be on a FUSE mount even if its path does *not* begin with $HOME/.gvfs . This situation occurs any time a symbolic link that points to a file under $HOME/.gvfs is created somewhere else in the system (e.g. /tmp).

I therefore think we should look up the gio:uri xattr even if the file path does not start with $HOME/.gvfs. If the xattr does not exist, that simply tells us this is not a FUSE file. Checking for the xattr is a more robust method than checking for the $HOME/.gvfs prefix.

I have a similar concern about symbolic links as described in commnt #11 of bug #530654.
Comment 25 Gavin Hamill 2008-10-03 11:35:58 UTC
Does this address drag-and-drop from nautilus into other apps, or is its scope restricted to launching files with their associated applications?

Comment 26 Matthias Clasen 2008-10-03 14:10:24 UTC
This has nothing to do with DND
Comment 27 Gavin Hamill 2008-11-22 21:40:55 UTC
In the interests of uniformity, should DND not be covered in the scope of this bug?

i.e. Why should double-clicking an icon invoke different behaviour from dragging the same icon into a target application's already-open window?

Comment 28 Gavin Hamill 2009-08-06 21:06:37 UTC
Just a little re-open for this.

These patches have bitten me on the backside a little.

Opening a Nautilus window to "/home/gdh/.gvfs" shows one directory - "mp3 on eddie"

If I double click on that (so I can drag/drop mp3's into an Audacious playlist) Nautilus cleverly opens "smb://eddie/mp3/" instead.. I'm now completely unable to open any POSIX path starting with /home/gdh/.gvfs in Nautilus!

If I've manually browsed to a hidden directory like ~/.gvfs, shouldn't that be an indication that I know what I'm doing?
Comment 29 David Zeuthen (not reading bugmail) 2009-08-09 23:14:59 UTC
(In reply to comment #28)
> Just a little re-open for this.
> 
> These patches have bitten me on the backside a little.
> 
> Opening a Nautilus window to "/home/gdh/.gvfs" shows one directory - "mp3 on
> eddie"
> 
> If I double click on that (so I can drag/drop mp3's into an Audacious playlist)
> Nautilus cleverly opens "smb://eddie/mp3/" instead.. I'm now completely unable
> to open any POSIX path starting with /home/gdh/.gvfs in Nautilus!
> 
> If I've manually browsed to a hidden directory like ~/.gvfs, shouldn't that be
> an indication that I know what I'm doing?

Sounds more to me like Nautilus drag/drop code is doing it wrong - it really should be passing the path using g_file_get_path() just like GDesktopAppInfo and friends is doing... that way the FUSE path "/home/gdh/.gvfs/mp3 on eddie/mp3/foo.txt" will be passed when you are dragging the file foo.txt from file manager window showing the location "smb://eddie/mp3"....


Comment 30 Gavin Hamill 2009-08-09 23:34:26 UTC
Hi David,

Yep, I agree completely.. see comments #25, #26, #27 in this bug. I was really pleased at the time that the current implementation went live. I believe it's now a great time (yes, speaking as a non coder) to complete this work for full compatibility and a uniform user experience.

In the interim I've changed the .desktop file for audacious so that a double-click will  '-e' enqueue rather than open the file directly. I don't expect most users should have to resort to such hacks. Plus, audacious is only a single use case...
Comment 31 Gavin Hamill 2009-08-15 01:25:37 UTC
Just out of curiosity, is there any chance this POSIX-compliant D-n-D support will go in to 2.28? I notice there's a month until the hard freeze - is there substantial work required to achieve this functionality? (again, I am a non-coder)

:)
Comment 32 David Zeuthen (not reading bugmail) 2009-08-17 18:38:04 UTC
(In reply to comment #31)
> Just out of curiosity, is there any chance this POSIX-compliant D-n-D support
> will go in to 2.28? I notice there's a month until the hard freeze - is there
> substantial work required to achieve this functionality? (again, I am a
> non-coder)

I would start by filing a bug against Nautilus, referencing this bug...
Comment 33 Gavin Hamill 2009-08-18 09:16:25 UTC
Cool, hence bug 592125 - wasn't sure of the correct procedure :)