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

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

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: http://bugzilla.gnome.org/show_bug.cgi?id=566747

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.

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

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.

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)

Indeed, reopening.

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.

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.

gvfs -> glib-2.0

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.

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

> 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.

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

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.

This has been fixed properly upstream now.

Here's a debdiff with the upstream change.

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

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)

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

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.

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

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.

Here's a debdiff that fixes this

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