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