g_file_new_for_path() is (reasonably) implemented as:

  return g_vfs_get_file_for_path (g_vfs_get_default (), path);

which is just a vcall:

  return (* class->get_file_for_path) (vfs, path);

In gvfs this is:

  file = g_vfs_get_file_for_path (G_DAEMON_VFS (vfs)->wrapped_vfs, path);
  file = convert_fuse_path (vfs, file);
  return file;


with

  vfs->wrapped_vfs = g_vfs_get_local ();



In short: we spin up the entire GIOModule/GIOExtensionPoint framework, load a lot of modules, initialise gvfs and call into it just for the purpose of calling back into the 'local' VFS module in GIO.

The only case where gvfs does anything at all is if we are giving it a path inside of the fuse root.  In that case, it appears to be attempting to convert it back to a native GIO URI.

I propose modifying g_file_new_for_path() to short-circuit this insanity and go straight to the local vfs implementation.  We can deal with the FUSE case by avoiding the short-circuit for anything that looks like it might be a FUSE path (which we could just determine using the same algorithm gvfs does).

We could also possibly modify the for_uri case as well, for file:/// URIs.

I suppose it's also possible that we could have a non-gvfs gvfs implementation that does something stranger with local paths...