After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 696279 - Set the activation root on GoaVolume
Set the activation root on GoaVolume
Status: RESOLVED FIXED
Product: gvfs
Classification: Core
Component: goa volume monitor
git master
Other All
: Normal normal
: ---
Assigned To: Debarshi Ray
gvfs-maint
: 700323 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2013-03-21 12:11 UTC by Debarshi Ray
Modified: 2013-06-18 23:38 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
GDaemonFile: fix relative path handling to account for mount_prefix (4.12 KB, patch)
2013-06-02 18:24 UTC, Giovanni Campagna
committed Details | Review
GProxyVolume: extend the protocol so the volume monitor can force a call to Mount (3.87 KB, patch)
2013-06-02 18:24 UTC, Giovanni Campagna
needs-work Details | Review
goa: export the activation root for volumes (3.00 KB, patch)
2013-06-02 18:24 UTC, Giovanni Campagna
needs-work Details | Review
GProxyVolume: extend the protocol so the volume monitor can force a call to Mount (4.93 KB, patch)
2013-06-13 17:30 UTC, Giovanni Campagna
committed Details | Review
goa: export the activation root for volumes (3.36 KB, patch)
2013-06-13 17:41 UTC, Giovanni Campagna
committed Details | Review

Description Debarshi Ray 2013-03-21 12:11:58 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
Comment 1 Matthias Clasen 2013-05-17 02:48:41 UTC
*** Bug 700323 has been marked as a duplicate of this bug. ***
Comment 2 Giovanni Campagna 2013-06-02 18:23:37 UTC
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.
Comment 3 Giovanni Campagna 2013-06-02 18:24:14 UTC
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)
Comment 4 Giovanni Campagna 2013-06-02 18:24:18 UTC
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.
Comment 5 Giovanni Campagna 2013-06-02 18:24:23 UTC
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.
Comment 6 Debarshi Ray 2013-06-10 14:18:43 UTC
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?
Comment 7 Giovanni Campagna 2013-06-10 18:41:06 UTC
(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
Comment 8 Alexander Larsson 2013-06-13 13:47:02 UTC
Review of attachment 245874 [details] [review]:

Looks right to me.
Comment 9 Alexander Larsson 2013-06-13 14:14:36 UTC
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.
Comment 10 Alexander Larsson 2013-06-13 14:20:58 UTC
Review of attachment 245876 [details] [review]:

Looks good, although needs updating to use the flag in the other patch
Comment 11 Debarshi Ray 2013-06-13 14:56:25 UTC
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.
Comment 12 Giovanni Campagna 2013-06-13 17:30:00 UTC
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.
Comment 13 Alexander Larsson 2013-06-13 17:31:55 UTC
Review of attachment 246747 [details] [review]:

ack
Comment 14 Giovanni Campagna 2013-06-13 17:41:21 UTC
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.
Comment 15 Alexander Larsson 2013-06-13 18:52:48 UTC
Review of attachment 246753 [details] [review]:

ack
Comment 16 Giovanni Campagna 2013-06-13 19:10:26 UTC
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
Comment 17 Adam Williamson 2013-06-13 19:17:53 UTC
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...
Comment 18 Alexander Larsson 2013-06-14 06:59:19 UTC
Yeah, it should be safe to backport.
Comment 19 Adam Williamson 2013-06-14 07:31:16 UTC
It'd be great if we could get that in by final freeze (June 18). I'll talk to mclasen about it tomorrow. thanks!
Comment 20 Alexander Larsson 2013-06-14 10:51:37 UTC
1.16.3 has the fix
Comment 21 Adam Williamson 2013-06-18 23:38:25 UTC
Confirming the fix looks good in 1.16.3, awesome. Thanks.