regression - URIs opened with firefox %u load as local files (file:///...)

Bug #314263 reported by Bryce Harrington on 2009-01-06
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Fix Released
glib2.0 (Ubuntu)
Chris Coulson
Chris Coulson

Bug Description

[Affects] glib2.0-2.19.3 (regression from 2.18.x)

'Open Link' in GNOME apps like gnome-terminal or xchat-gnome loads a "" URI in firefox as "file:///bar".

Between 2.18.3 and 2.19.2, the expand_macro() routine in glib's gdesktopappinfo.c altered how the %u macro is handled. It now treats them as %f macros instead. The new code that does this is shown below.

00558 /* On %u and %U, pass POSIX file path pointing to the URI via
00559 * the FUSE mount in ~/.gvfs. Note that if the FUSE daemon isn't
00560 * running or the URI doesn't have a POSIX file path via FUSE
00561 * we'll just pass the URI.
00562 */
00563 switch (macro)
00564 {
00565 case 'u':
00566 force_file_uri_macro = 'f';
00567 force_file_uri = TRUE;
00568 break;
00569 case 'U':
00570 force_file_uri_macro = 'F';
00571 force_file_uri = TRUE;
00572 break;
00573 default:
00574 force_file_uri_macro = macro;
00575 force_file_uri = FALSE;
00576 break;
00577 }

According to ps, I do have gvfs running:
bryce 5678 0.0 0.0 68884 2280 ? Ssl Jan04 0:00 /usr/lib/gvfs//gvfs-fuse-daemon /home/bryce/.gvfs

The ~/.gvfs directory is empty, and lsof does not show it in use. From the comment in the code above it sounds as if shutting down gvfs-fuse-daemon and/or gvfsd would cause it to not switch %u for %f, however killing either or both of them seems to have no effect.

Bryce Harrington (bryce) wrote :
Bryce Harrington (bryce) wrote :

As a workaround, I just deleted the aforementioned code, and the problem was resolved.

Bryce Harrington (bryce) on 2009-01-06
Changed in glib2.0:
milestone: none → jaunty-alpha-5
Chris Coulson (chrisccoulson) wrote :

Thank you for your bug report. This bug has been reported to the developers of the software. You can track it and make comments here:

Changed in glib2.0:
importance: Undecided → High
status: New → Triaged
Changed in glib:
status: Unknown → New
Bryce Harrington (bryce) wrote :

Problem reoccurred after upgrading to glib2.0_2.19.4-0ubuntu1 and rebooting a few times.

Note that in the upstream bug they believe their code is fine and that it's a downstream problem.

Chris Coulson (chrisccoulson) wrote :

Thanks for liasing with upstream about this Bryce. Anyway, based on David's comments, I'm going to re-assign this to gvfs.

Changed in gvfs:
assignee: nobody → desktop-bugs
Martin Pitt (pitti) wrote :

Bryce says that his workaround was killed by a recent gvfs update, and the bug hasn't happened for him any more, so he considers this fixed.

Changed in gvfs:
status: Triaged → Fix Released
Chris Coulson (chrisccoulson) wrote :

Martin - there are some duplicates of this which seem to be still very much a problem (ie, this still happens when you run gnome-open with sudo)

Martin Pitt (pitti) wrote :

Indeed, reopening.

Changed in gvfs:
status: Fix Released → Confirmed
Chris Coulson (chrisccoulson) wrote :

I started doing a little bit of debugging on this last night. I'll continue again this afternoon when I get home from work and I'll let you know if I figure out whats going on.

Chris Coulson (chrisccoulson) wrote :

Right, I've done some initial debugging in to this, by putting some g_debug's in so I get an understanding of what the difference is between with/without sudo.

In the working case, in expand_macro_single(), g_file_new_for_uri() returns a GDaemonFile, and then g_file_get_path() on that GDaemonFile returns NULL. This stops the %U macro being replaced with %F.

In the non-working case, g_file_get_path() actually doesn't return NULL. After looking at the debug output, it seems that g_file_new_for_uri() actually returns a GDummyFile (not a GDaemonFile). This is because g_vfs_get_default() returns a GLocalVfs (instead of a GDaemonVfs), forcing a different code-path.

The reason for this is that when you use sudo, the GVFS daemon is not contactable because sudo scrubbed DBUS_SESSION_BUS_ADDRESS from the environment. This has most likely always been the case. In this case, the GLocalVfs should allow you to run gio applications when the GVFS daemon is not contactable. This ability has clearly regressed now.

Bryce was correct initially with his assessment of the expand_macro() function - however, the changes merely just exposed a bug that has probably been there all along.

So, my next question is - is the behaviour of g_file_get_path() correct when you pass it a GDummyFile?

And I'm pretty convinced this is a glib bug again, and not a gvfs bug.

Chris Coulson (chrisccoulson) wrote :

gvfs -> glib-2.0

Chris Coulson (chrisccoulson) wrote :

I've written a patch that makes g_file_get_path() return NULL for a GDummyFile that has a URI other than file:///

I've tested it with the apport-gtk use-case (sudo -H -u <uid> gnome-open <url>) and it's working fine. I've attached a debdiff, and I'll send the patch upstream too.

Changed in glib2.0:
status: Confirmed → Triaged
Chris Coulson (chrisccoulson) wrote :

Here's a slightly corrected version. This one contains a g_free() for the uri_scheme string

A. Walton (awalton) wrote :

> So, my next question is - is the behaviour of g_file_get_path() correct when you pass it a GDummyFile?

Correct in what way? The GDummyFile does its best to parse "regular" URIs (those that fall into the "scheme://host/path/" category), but will give up if the URI is not of that simplistic form and simply return NULL. So if you're passing in an HTTP URI, it should be doing the "right" thing (returning the "path" part of the URI; in the "scheme://host/path1" case, "path1"), but all bets are off if you stray much from that.

The reason the GDaemonFile currently returns NULL when you call get_path() is because reverse-mapping FUSE paths to GVFS URIs isn't complete yet.

Speaking to the problem above, it seems to be that something somewhere (whether it's in GIO itself, or in gnome-open) is roundtripping through GFile (g_file_new_from_[path/uri]->g_file_get_[uri/path]->g_file_new_from_[uri/path]), which is not a lossless process. In that case, you will get strange URIs like the ones you're seeing above. I hate to say that the suggestion is "don't-do-it", and that it will likely never be a 100% lossless process.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package glib2.0 - 2.19.5-0ubuntu3

glib2.0 (2.19.5-0ubuntu3) jaunty; urgency=low

  * 70_g_file_get_path_fix.patch:
    - Make g_file_get_path() return NULL for GDummyFile
      objects with a URI that is not file:/// (LP: #314263)

 -- Chris Coulson <email address hidden> Fri, 30 Jan 2009 15:52:21 +0000

Changed in glib2.0:
status: Triaged → Fix Released
TJ (tj) wrote :

This is (was) affecting apport when it tries to open a bug-report URL. The current Jaunty alpha 3 release will suffer this (as well as bug #314212). When not using the latest daily CD images the solution is to do:

sudo apt-get update && sudo apt-get upgrade

This ensures the fixes are applied before doing any testing that might require bug-reports to be posted.

Chris Coulson (chrisccoulson) wrote :

This has been fixed properly upstream now.

Changed in glib2.0:
status: Fix Released → In Progress
assignee: desktop-bugs → chrisccoulson
Chris Coulson (chrisccoulson) wrote :

Here's a debdiff with the upstream change.

Changed in glib2.0:
status: In Progress → Triaged
Sebastien Bacher (seb128) wrote :

you use the new change but still the previous workaround, is that required?

Chris Coulson (chrisccoulson) wrote :

Hi Sebastien - it seems that the previous workaround isn't actually in the newer 2.19.6-0ubuntu1 version of glib (it was only in 2.19.5-0ubuntu3)

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package glib2.0 - 2.19.6-0ubuntu2

glib2.0 (2.19.6-0ubuntu2) jaunty; urgency=low

  * Reapply revisions which were not in the previous upload
  * Don't use the previous workaround but rather the svn change

  [ Chris Coulson ]

  * 70_get_path_fix_from_svn:
    - GDummyFile's are never used for local files, so always
      return NULL in g_dummy_file_get_path() (LP: #314263).

 -- Sebastien Bacher <email address hidden> Sat, 07 Feb 2009 17:01:08 +0100

Changed in glib2.0:
status: Triaged → Fix Released
Andy Whitcroft (apw) wrote :

I am not finding this bug fixed by the changes in glib-2.19.6-0ubuntu2. Specifically apport reports do not seem to work with the url becoming a file:///ubuntu/... reference.

At pitti's suggestion I rebuilt the previous version of glib and downgraded to that, libglib2.0-0_2.19.5-0ubuntu3_i386.deb specifically, only changing that one package has fixed things for me. apport reports now correcly connect to launchpad. It looks like the 'proper' fix does not work.

Changed in glib2.0:
status: Fix Released → Triaged
Sebastien Bacher (seb128) wrote :

unsubscribing the sponsor team since there is nothing to sponsor there right now

Chris Coulson (chrisccoulson) wrote :

That's really odd. The official upstream patch actually does exactly the same as what my original workaround did (returns NULL from g_dummy_file_get_path, although it does it unconditionally now). This suggests that something else changed from 2.19.5 -> 2.19.6. I'll take a look at this again tomorrow.

Chris Coulson (chrisccoulson) wrote :

Here's a debdiff that fixes this

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package glib2.0 - 2.19.6-0ubuntu4

glib2.0 (2.19.6-0ubuntu4) jaunty; urgency=low

  * 70_get_path_fix_from_svn.patch:
    - Updated so that it applies correctly (LP: #314263).

 -- Chris Coulson <email address hidden> Fri, 13 Feb 2009 17:11:12 +0000

Changed in glib2.0:
status: Triaged → Fix Released
Changed in glib:
status: New → Fix Released
Changed in glib:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.