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 509606 - Auto busy on unmount
Auto busy on unmount
Status: RESOLVED FIXED
Product: gvfs
Classification: Core
Component: daemon
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gvfs-maint
gvfs-maint
Depends on:
Blocks:
 
 
Reported: 2008-01-15 11:37 UTC by Alexander Larsson
Modified: 2011-06-07 12:38 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch (8.26 KB, patch)
2008-03-22 11:00 UTC, Carlos Garcia Campos
none Details | Review
Updated patch (13.29 KB, patch)
2008-04-05 10:19 UTC, Carlos Garcia Campos
reviewed Details | Review
Another update (13.48 KB, patch)
2008-04-16 08:22 UTC, Carlos Garcia Campos
reviewed Details | Review

Description Alexander Larsson 2008-01-15 11:37:22 UTC
When there are open files on a mount we should automatically fail unmount requests with G_IO_ERROR_BUSY (unless G_MOUNT_UNMOUNT_FORCE is specified).
Comment 1 Carlos Garcia Campos 2008-03-22 11:00:58 UTC
Created attachment 107788 [details] [review]
Patch

This patch includes:

 - A g_vfs_backend_is_busy function that returns TRUE if the daemon has gvfschannels active
 - Unmount flags parameter is retrieved from the DBus message when creating the unmount job
 - When trying to unmount, if the backend is busy and Force flag is not present a G_IO_ERROR_BUSY error is returned.
 - A -f command line option to gvfs-mount to be able to force unmount. 

I still have some doubts about the current behaviour and possible improvements:

 - g_vfs_backend_is_busy could be g_vfs_backend_get_n_channels instead so that the error message would include the number of open files instead of just "File system is busy"
 - The Force flag is only checked in the try method, assuming that unmount will only be called if try didn't succeed. So, the question is, should we pass the force flag to the backends? or is right to assume that if unmount is called is because the backend is not busy or the force flag is present?
 - Should the unmount job close the active channels when force flag is present?
Comment 2 Alexander Larsson 2008-03-25 15:37:34 UTC
I dunno if getting a number of open files is better than is-busy. However, if we could get the filename of the open file (at least in the case there is only one open) that may be nice...

I think we should pass in the force flag. Some backend may need to do something special with it. 

I think we should close active channels on force flag. Its similar to a force shutdown from the backend itself, which should also do this.
Comment 3 Alexander Larsson 2008-03-25 15:38:14 UTC
Oh, and btw, lets wait with this one to post-branch.
Comment 4 Carlos Garcia Campos 2008-04-05 10:19:21 UTC
Created attachment 108661 [details] [review]
Updated patch

New version of the patch.
Comment 5 Matthias Clasen 2008-04-16 03:57:57 UTC
We have branched now.

Looks like g_vfs_backend_close_active_channels leaks the channels list.

Comment 6 Carlos Garcia Campos 2008-04-16 08:22:48 UTC
Created attachment 109358 [details] [review]
Another update

Here is a new version against current trunk and with the leak fixed.
Comment 7 Matthias Clasen 2009-01-10 03:26:30 UTC
Patch looks good to me. 
Alex, should we get this in this cycle ?
Comment 8 Christian Kellner 2011-06-07 12:38:33 UTC
Fixed on git master. 

Updating 08c4a19..100ea69
Fast-forward
 daemon/gvfsbackend.c    |   29 +++++++++++++
 daemon/gvfsbackend.h    |    3 +
 daemon/gvfschannel.c    |   45 ++++++++++++++++++++
 daemon/gvfschannel.h    |    2 +-
 daemon/gvfsdaemon.c     |   16 +++++++
 daemon/gvfsdaemon.h     |    3 +
 daemon/gvfsjobunmount.c |  106 +++++++++++++++++++++++++++++++++++++++-------
 7 files changed, 187 insertions(+), 17 deletions(-)