GMountOperation issues

[David Zeuthen <david fubar dk>]

Hey,

I'm working on a DeviceKit-disks backend for GVfs. The plan is that it
will replace the HAL backend. One difference is that it doesn't use any
GUI helper for mounting (the HAL backend depends on gnome-mount to do
the heavy lifting).

So for LUKS volumes the DeviceKit-disks backend uses GMountOperation. I
have a patch for the proxy monitor stuff to proxy GMountOperation to the
volume monitor process but that's besides the point.

Here are some issues with current GMountOperation

 - What should g_volume_mount() do if the user cancels the dialog?

   With ftp://blah ftp gnome org and dismissing the auth dialog I get
   a modal error dialog back saying "Access was denied". I don't think
   that's useful; I've already indicated that I wanted to bail.

   First of all the function needs to return an error because we want to
   guarantee that if this functions succeeds then g_volume_get_mount()
   will return non-NULL upon returning. This is even spelled out in the
   docs [1]; I remember adding that when we ported Nautilus to GIO.

   Resolution: State in the docs for g_volume_mount() that
   implementations MUST return G_IO_ERROR_FAILED_HANDLED upon
   receiving G_MOUNT_OPERATION_ABORTED.

   Alternative resolution: fix up all users to avoid showing error
   dialogs if they cancel.

 - What should happen if the resource that the user is trying to mount
   is removed while the authentication dialog is being shown?

   A very real example of this is an auth dialog for LUKS on a USB
   stick. I think the only real resolution here, user experience wise,
   is to remove the auth dialog and not show any errors. That's what
   gnome-mount has been doing for several years.

   The way it works today is that the auth dialog keeps showing even
   after g_volume_mount() returns an error.

   I *think* this is just a GtkMountOperation bug; if the caller unrefs
   the GtkMountOperation and it shows a dialog, the dialog *should* be
   destroyed. Right now this doesn't happen because the function
   gtk_mount_operation_ask_password() takes a strong ref.

   But relying on weak refs to do stuff like make dialogs go away is
   rarely a good idea; it's way to easy to mess up reference counting.
   So perhaps the best solution is to have a ::cancelled signal on
   GMountOperation that g_volume_mount() can emit if the resource
   goes away.

   Resolution: State in the docs for g_volume_mount() that
   implementations MUST return G_IO_ERROR_FAILED_HANDLED if the
   resource being mounted is removed. Introduce ::cancelled signal
   on GMountOperation and add suitable docs.

 - GtkMountOperation hardcodes the word "Connect" in the user interface.
   This is not really helpful for things like LUKS devices where a
   better word would be "Unlock" or "Decrypt" or something else. It's
   also sort of a detail so I don't know if we want to throw API at
   fixing this.

Thoughts?

Btw, another feature from gnome-mount that I need to teach the
DeviceKit-disks GVfs backend about is showing a notification if
unmounting turns out to be taking a long time [2]. 

The naive solution here is to just make the volume monitor process poke
the notification daemon using D-Bus. However, I'm wondering if we want
move this functionality to Nautilus or maybe throw some API at it? I
don't know.

Thanks,
David


[1] :

http://library.gnome.org/devel/gio/unstable/GVolume.html#g-volume-mount

[2] :

The heuristic currently used in gnome-mount is that if the Unmount()
call on HAL is pending for more than 750ms we show a notification
saying 

  There is data that needs to be written to the device %s before it can
  be removed. Please do not remove the media or disconnect the drive.

When the Unmount() call terminates we replace this notification bubble
with

 The device %s is now safe to remove