I guess the real question here is: what is g_vfs_get_local() good for ?

The only way to use a different implementation currently is to set GIO_USE_VFS=local in the environment.

(In reply to comment #1)
>
> The only way to use a different implementation currently is to set
> GIO_USE_VFS=local in the environment.

Well alex said I could use g_vfs_get_local() too.  The problem with setting an environment variable is mainly that it would propagate into any child processes, which I don't want.  (For example, say I spawn an editor from $EDITOR)

Created attachment 204103 [details] [review]
gio: Don't call g_vfs_get_default() on GFiles created through local VFS

My program is using GIO basically as "convenient Unix API wrapper",
like getting all data in g_malloc, allowing asynchronous operation
etc.  I don't ever want to do HTTP or FTP for example.

In particular the using default VFS implies connecting to the session
bus, which I definitely don't want to do (my program will in some
cases run as a root daemon).

Also, I tend to "profile" my app via "strace" to just get an idea of
what it's doing roughly - while connecting to the session bus isn't
expensive, it makes my strace profiles much uglier (for no benefit).

Before this patch, GIO had calls to g_vfs_get_default() scattered
randomly throughout GLocalFile, GLocalFileInfo etc.  This is ugly.  My
patch is effectively shifts the ugliness - I can't claim it's
beautiful.  One minor downside for example is we will start
instantiating the local VFS in apps that were just relying on
g_file_new_for_path().  (This is really pretty minor, it's just
another GObject).

Created attachment 204104 [details] [review]
gio: Don't call g_vfs_get_default() on GFiles created through local VFS

Missed "git add gio/gfile-priv.h"

Not a beauty, indeed. Do we really need all this tagging of individual objects ?
From my understanding, you simply want to _always_ use a local vfs instance, regardless of what the default is ? Wouldn't something like

g_vfs_set_default (gvfs_get_local ())

be a much more succinct way to achieve that ?

The idea that we may need to tag each object with its originating vfs, and propagate that along seems much more involved than simply being able to set the default.

the current GFile code seems backwards anyway... wouldn't it be more normal to have it emit a signal, which its parent VFS would catch and act on?

(Failing that, it seems like it would make more sense to tag the GFile with the GVfs itself, rather than a flag saying local-or-default.)

(In reply to comment #5)
> Not a beauty, indeed. Do we really need all this tagging of individual objects
> ?
> From my understanding, you simply want to _always_ use a local vfs instance,
> regardless of what the default is ? Wouldn't something like
> 
> g_vfs_set_default (gvfs_get_local ())
> 
> be a much more succinct way to achieve that ?

Well...further complicating things is that most of ostree is written as a library which I could imagine a gtk+ app wanting to use.  If I do something like the above, then it would break them.

Possibly what I could do is call that in main.c but not in the library.
 
I'll take a look.

(In reply to comment #6)
> the current GFile code seems backwards anyway... wouldn't it be more normal to
> have it emit a signal, which its parent VFS would catch and act on?

Mmm...that's probably one for alex to comment on.

> (Failing that, it seems like it would make more sense to tag the GFile with the
> GVfs itself, rather than a flag saying local-or-default.)

I started doing that originally, but then we're continually churning the refcount for the VFS instance as gfiles come and go; seemed ugly.

I think I'll just try g_vfs_set_default() instead.

Hi Colin,

Hmm, I don't _think_ what you want to achieve will work because of the guarantee that we map FUSE paths on file:/// back to GVfs URIs, e.g. this program

 gchar *uri;
 GFile *file;

 file = g_file_new_for_commandline_arg ("/home/davidz/.gvfs/SFTP\ on\ shell.lab.bos.redhat.com/home/boston/davidz/.bashrc");
 uri = g_file_get_get_uri (file);
 g_print ("%s\n", uri);
 g_free (uri);
 g_object_unref (file);

should print

 sftp://shell.lab.bos.redhat.com/home/boston/davidz/.bash_rc

Obviously for this to work, we need information from the GVfs daemon and the way it's implemented right now, I think, is that we do a D-Bus call (a smarter implementation may rely on a shared file in $XDG_RUNTIME_DIR to avoid the D-Bus call. But I don't think that's how things work right now.)

You might think this is a "pet feature" and we don't need it and so it's fine to break it ... but it is actually super important to have this because it is the corner-stone used to ensure interoperability between GVfs-using apps and non-GVfs-using apps (because we always pass POSIX-compliant paths when launching apps). For example, if we didn't have this we'd launch e.g. 'mplayer sftp://shell.lab.bos.redhat.com/home/boston/davidz/foo.avi' from your file manager and obviously this would not work at all. See

 http://developer.gnome.org/gio/unstable/GAppInfo.html#GAppInfo.description

for further information.

I have the same problem too in udisks btw, my solution is to do this

 http://cgit.freedesktop.org/udisks/tree/src/main.c?id=1.90.0#n106

e.g. the environment variable hack.

Btw, bug 526454 is obviously related and has additional discussion (maybe this bug is even a duplicate, dunno).

Review of attachment 204104 [details] [review]:

::: gio/glocalfile.c
@@ +1175,3 @@
+      class = G_VFS_GET_CLASS (vfs);
+      if (class->local_file_moved)
+	class->local_file_moved (vfs, local->filename, new_local->filename);

This isn't right at all. We want to chain this to the real vfs instance.
For instance, the GVfs implementation of this is what ensures that metadata follow files around when moved.

@@ +1255,3 @@
+	  class = G_VFS_GET_CLASS (vfs);
+	  if (class->add_writable_namespaces)
+	    class->add_writable_namespaces (vfs, list);

Similarly here, GVfs adds the "metadata" namespace as writable for local files.

@@ +1480,3 @@
+      class = G_VFS_GET_CLASS (vfs);
+      if (class->local_file_removed)
+	class->local_file_removed (vfs, local->filename);

Also used for metadata

@@ +2061,3 @@
+      class = G_VFS_GET_CLASS (vfs);
+      if (class->local_file_moved)
+	class->local_file_moved (vfs, local->filename, trashfile);

etc

@@ +2367,3 @@
+      class = G_VFS_GET_CLASS (vfs);
+      if (class->local_file_moved)
+	class->local_file_moved (vfs, local_source->filename, local_destination->filename);

etc

::: gio/glocalfileinfo.c
@@ +1748,3 @@
+                                      NULL,
+                                      &parent_info->extra_data,
+                                      &parent_info->free_extra_data);

This is needed to get metadata for local files.

The env var hack works, but we could also add an "early" set_default_vfs call to make this a bit cleaner (and more extensible, you could for instance supply an app-specific vfs implementation).

*** Bug 691618 has been marked as a duplicate of this bug. ***

Bug #691618 has some other ideas and a bit of discussion about this.

*** Bug 793187 has been marked as a duplicate of this bug. ***

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/483.