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. -- regression - URIs opened with firefox %u load as local files (file:///...) https://bugs.launchpad.net/bugs/314263 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
