Created attachment 280691 [details]
Use file:/// URI prefix on W32

> uri = g_strconcat ("file://", icon_info->filename, NULL);
> ...
> g_file_new_for_uri (uri=uri@entry=0x4327970 "file://F:\\e31\\mingw\\share\\icons\\Adwaita\\16x16/status\\image-missing.png") at gfile.c:6302

that doesn't end well - URI handler in glib does no understand URIs that look like "file://X:...".
Apparently, "file://" means that the path part of the URI is a relative path, and CWD is prepended to it.
Or, as it's been pointed out for me, the part before first "/" is considered to be a "host", and the rest is a "path". Since the URI does contain a single "/" (by accident - both "/" and "\\" work as dir separators on W32, so this is allowed), the whole thing before it is "host", and the rest is a "path". That still doesn't explain why i get something like this:
> 1345      fd = g_open (local->filename, O_RDONLY|O_BINARY, 0);
> (gdb) p local->filename
> $26 = (gchar *) "F:\\e31\\mingw\\bin\\file:\\F:\\e31\\mingw\\share\\icons\\Adwaita\\16x16\\status\\image-missing.png"
down the road with such URI.

Currently https://git.gnome.org/browse/gtk+/commit/?id=5a252f13a863c00ccd9901afa110e85836a6af4c is pushed as a fix. It probably works (haven't had a chance to test it), but there are other ways.

One way is to use "file:///" prefix, which would cause the path part of the URI to be used as-is (and assumed to be absolute path). I've attached a patch (probably not good enough for pushing) that does fix things for me this way.

Another way is to change g_file_new_for_uri() (that is, glib) to be able to handle "file://X:..." URIs (at least on Windows).