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 517071 - Need mainloop-less way of mounting
Need mainloop-less way of mounting
Status: RESOLVED WONTFIX
Product: glib
Classification: Platform
Component: gio
unspecified
Other All
: Normal normal
: ---
Assigned To: Alexander Larsson
gtkdev
Depends on:
Blocks:
 
 
Reported: 2008-02-17 20:32 UTC by René Stadler
Modified: 2009-02-25 15:02 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description René Stadler 2008-02-17 20:32:19 UTC
For the GStreamer gio elements, we cannot rely on somebody to iterate the default main context since gst does not have this requirement at all (unlike gtk).

Specifically, g_file_mount_enclosing_volume relies on having a main loop running.

Furthermore, GMountOperation also seems to need it.  For instance, the default ask-password, ask-question signal handlers idly defer emission of the fallback reply signal to the default main context.
Comment 1 Alexander Larsson 2008-02-18 10:20:56 UTC
The reason mount operations are async is that making them sync is more or less impossible to get right. The problems gnome-vfs had from this is a large part of why it had to be rewritten.

There are cases where a mount operation can work synchronously, but as soon as there needs to be some form of authentication or other user interaction things get very problematic.

What do you expect the gstreamer source to do when the mount operation requires you to enter a password?
Comment 2 René Stadler 2008-02-18 12:47:07 UTC
When the mount operation requires a password, the element needs to signal that to the application (custom element message or a new message type) and error out.  It's not possible to get user interaction during the state change (apparently gnomevfs allows this by installing a global callback).

The app could then collect the credentials in whatever way it likes and either pass this information to the element or mount the location itself.

The mainloop-free mounting is needed so that credential-free locations can be accessed without extra app interaction.  Without that, the gio elements cannot be transparently autoplugged and thus never replace the gnomevfs elements.

Now that I think of it, a mainloop-free GMountOperation is not strictly needed.  It would just mean that an app that provides password entering must use a main loop.  The gio elements would then require that applications mount locations that need credentials on their own.
Comment 3 Alexander Larsson 2008-02-18 15:02:25 UTC
Pushing the need to auth back to the app via some message, letting the app handle it sounds like a reasonable approach. In fact, its exactly the approach gio uses. It gives back G_IO_ERROR_NOT_MOUNTED and lets the app handle it.
Comment 4 Alexander Larsson 2009-02-25 15:02:57 UTC
Closing this then, as pointed out above its solvable for gstreamer, and in general its a bad idea to try to mount sync.