GNOME Bugzilla – Bug 528559
Add details for applications blocking a device
Last modified: 2009-12-20 03:47:54 UTC
Attaching a draft patch using lsof, it needs to test if lsof call failed among other things missing.
Created attachment 109416 [details] [review] 20080417_bgo_528559_blocking.diff: Implements a treeview with lsof :)
Created attachment 109417 [details] How it looks This is how it looks. Info is get from .desktop files, oh yes it also needs to check for more paths maybe and not just the hardcoded one.
This is definitely very interesting, thanks for hacking on this. I'll have a look at the patch later tonight.
Eeek. Please tell me if you make progress on this, as it's very likely that I'll mentor this project for openSUSE's Summer of Code 2008. It's nice to see that we already have a starting point thanks to Dieguito :)
Btw, maybe we want this in gvfs proper to also handle busy vfs mounts. And just make gnome-mount reliably being able to return EBUSY so the gvfs backends can handle it. There are some thoughts in the 2nd half of this mail http://mail.gnome.org/archives/gtk-devel-list/2007-December/msg00274.html What do you think?
(In reply to comment #5) > Btw, maybe we want this in gvfs proper to also handle busy vfs mounts. And just > make gnome-mount reliably being able to return EBUSY so the gvfs backends can > handle it. There are some thoughts in the 2nd half of this mail > > http://mail.gnome.org/archives/gtk-devel-list/2007-December/msg00274.html > > What do you think? > Interesting, I was thinking about that too but didn't really worry about it. The code can be easily pasted somewhere else, maybe something implemented in "gtk_io_*" would do something smarter than lsof, but still it's quite independent right now. So if I get it correctly, the "right thing" would be: - make gvfs scream G_IO_ERROR_BUSY when busy - have a g_mount_list_open_files() to know which files are in use and by whom in such mount (I'm ubber guessing a GList of "something"s would be returned containing {pid, executable, file}, atleast I only care about those) - get something to fire for G_IO_ERROR_BUSY (I'm not clear about how this would fit with current hal error) - launch the gio busy dialog when the signal is catched in gnome-mount (or something else) I ignore how hal, gio, gvfs and gnome-mount are playing together right now :) Btw, the icon->pixbuf function was stolen from nautilus, I forgot to add a note :p. (In reply to comment #4) > Eeek. Please tell me if you make progress on this, as it's very likely that > I'll mentor this project for openSUSE's Summer of Code 2008. > > It's nice to see that we already have a starting point thanks to Dieguito :) > Eeek²!. Well, it's nice to know that there's someone waiting to work on the rest of this. If such project is accepted let me know so I pass the baton to your student.
*** Bug 530312 has been marked as a duplicate of this bug. ***
Just FWIW, I've just implemented this feature in libgdu which will form the basis for the next version of gnome-mount (and also power gnome-disk-utility and gvfs volume monitoring). http://people.freedesktop.org/~david/gdu-fs-busy.png http://gitweb.freedesktop.org/?p=users/david/DeviceKit-disks.git;a=commitdiff;h=a878a7fa418e20d617a937c5d2a4d136d93c5b39 http://gitweb.freedesktop.org/?p=users/david/gnome-disk-utility.git;a=commitdiff;h=6b4870e7ec566dae67ad2767d4ec4d965b007fb7 I did this a bit differently: - the daemon does the lsof(1) call so we also get processes owned by other users (typically uid 0) - locked down by PolicyKit - we return /proc/pid/cmdline, not /proc/pid/exe - the dialog itself polls the daemon every second so the list is practically updated in real-time - once the list is empty the user can click "Unmount" button - there's no Kill button yet; I don't think we need one, it's not the right way to end processes anyway. The idea is that the user can see what processes he needs to end himself.
Oh, nevermind then :p.
Great! But IMHO a kill button would be nice because sometimes background processes hang and block the volume. This was reported many times in Ubuntu, and was one of the main interests of having such a feature. Ending himself a process is not accessible to most users (command line). Maybe a SIGTERM first, and then possibly a dialog asking whether to send a SIGKILL (for unresponding processes) would do the trick, just like we do know we the close button of the window manager. That would be more consistent on a desktop-wide approach.
I am really glad to see there is work on this. David, I am impressed with your dialog, especially the polling option and button to unmount once conflicts have been resolved. I agree with others however that some sort of end/kill/close should exist, as often the issue can be that the offending application isn't acting particularly friendly. (siderant: why does a terminal at a mounted location mean you can't unmount it? why doesn't it just cd ~/, for example, like nautilus (sometimes) does). Anyway, SIGTERM first, dialog with SIGKILL after delay seems reasonable. Federico, do you or anyone else know the status of this as far as GSoC is concerned? Is it being worked on and if so did someone start from one of the above implementations? I hate to see good work by people who know what they are doing scrapped and reimplemented. And finally, is there a target/potential version for this? Thanks everyone!
This would be a great feature if this could be implemented. Can I do anything for testing? I am using Ubuntu 8.10 and have a little experience with programming, but am willing to help getting this on the move.
So this was done in gdu extension for nautilus I think. So, obsolete.