GNOME Bugzilla – Bug 696279
Set the activation root on GoaVolume
Last modified: 2013-06-18 23:38:25 UTC
Unless we set the activation root on the volumes, the shadow-mount machinery won't work. As a result, UIs like Nautilus and GtkFileChooser will end up showing both the GVolume and the GMount. That is not what we want. Instead we want it to behave the way USB sticks work, where there is only one entry representing both the GVolume and the GMount. Initially it was a deliberate decision not to set the activation root. [1] Otherwise attempts to mount the GoaVolume [2] would not result in the mount_fn [3] being called so that we can feed the credentials from GOA when mounting. However, that would require elaborate hacks in GVfs for shadow-mounting to work. Instead we should set the activation root, and teach the respective GVfs backends to fetch the credentials (password or OAuth2 tokens) from GOA instead of feeding them from the volume monitor. [1] https://git.gnome.org/browse/gvfs/tree/monitor/goa/goavolume.c#n307 [2] https://git.gnome.org/browse/gvfs/tree/monitor/proxy/gproxyvolume.c#n879 [3] https://git.gnome.org/browse/gvfs/tree/monitor/goa/goavolume.c#n381
*** Bug 700323 has been marked as a duplicate of this bug. ***
I found a simpler solution: I taught GProxyVolume to call Mount on the volume monitor instead of going straight to gvfsd. I also found a few bugs related to shadow mounts, so I'll attach all patches here.
Created attachment 245874 [details] [review] GDaemonFile: fix relative path handling to account for mount_prefix If two files have two different origins (say, one from g_mount_get_root() and one from g_file_new_for_uri()), the mount_spec they use could expose a different mount_prefix, even if the represent the same URI and network object. This in particular fixes the handling of shadow mounts for dav (which rewrites the mount_spec during mount to find the right prefix)
Created attachment 245875 [details] [review] GProxyVolume: extend the protocol so the volume monitor can force a call to Mount Some volume monitors, like gnome-online-accounts, want their mount implementation to be called even though the volume has an activation root. Allow them to advertise so using the expansion fields of the volume DBus representation.
Created attachment 245876 [details] [review] goa: export the activation root for volumes Now that we can be in charge of mounts even if we have the shadow mount infrastructure, we should export it so that tracking of the associated GDaemonMount works correctly.
This doesn't seem to work for me. I ran: $ /opt/libexec/gvfs-goa-volume-monitor & $ GVFS_DEBUG=all /opt/libexec/gvfsd -r Then added a ownCloud account and started Nautilus. I still see the volume and mount separately. Maybe I am missing something?
(In reply to comment #6) > This doesn't seem to work for me. I ran: > $ /opt/libexec/gvfs-goa-volume-monitor & > $ GVFS_DEBUG=all /opt/libexec/gvfsd -r > > Then added a ownCloud account and started Nautilus. I still see the volume and > mount separately. Maybe I am missing something? Did you restart nautilus or was it already running? It needs to pick the new libgioremote-volume-monitor.so
Review of attachment 245874 [details] [review]: Looks right to me.
Review of attachment 245875 [details] [review]: I can see why we'd normally want to use mount_enclosing_volume, as we then go directly to the mount from the client and get rid of the need to proxy auth around. However, it seems like this approach to the goa problem should work fine, as long as its not default. So, the client part here looks good to me. The daemon side is pretty ugly though, with g_object_set_data() magic. I prefer if we added a flags field to g_vfs_proxy_volume_monitor_daemon_main() and created an always-call-mount flag which affects all volumes in the monitor.
Review of attachment 245876 [details] [review]: Looks good, although needs updating to use the flag in the other patch
It works for me now. I am sure I had restarted Nautilus earlier, but this time I built myself a new GVfs RPM with your patches and installed it system wide. Works quite nicely.
Created attachment 246747 [details] [review] GProxyVolume: extend the protocol so the volume monitor can force a call to Mount Some volume monitors, like gnome-online-accounts, want their mount implementation to be called even though the volume has an activation root. Allow them to advertise so using the expansion fields of the volume DBus representation.
Review of attachment 246747 [details] [review]: ack
Created attachment 246753 [details] [review] goa: export the activation root for volumes Now that we can be in charge of mounts even if we have the shadow mount infrastructure, we should export it so that tracking of the associated GDaemonMount works correctly.
Review of attachment 246753 [details] [review]: ack
Attachment 245874 [details] pushed as bf50158 - GDaemonFile: fix relative path handling to account for mount_prefix Attachment 246747 [details] pushed as 97a4246 - GProxyVolume: extend the protocol so the volume monitor can force a call to Mount Attachment 246753 [details] pushed as 7aa0c53 - goa: export the activation root for volumes
Would this be safe enough to backport for GNOME 3.8 (Fedora 19)? As the OwnCloud stuff is a pretty hyped of GNOME 3.8 it'd be kinda nice for it to work 'prettily' OOTB...
Yeah, it should be safe to backport.
It'd be great if we could get that in by final freeze (June 18). I'll talk to mclasen about it tomorrow. thanks!
1.16.3 has the fix
Confirming the fix looks good in 1.16.3, awesome. Thanks.