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 528559 - Add details for applications blocking a device
Add details for applications blocking a device
Status: RESOLVED OBSOLETE
Product: gnome-mount
Classification: Deprecated
Component: programs
unspecified
Other Linux
: Normal normal
: ---
Assigned To: David Zeuthen (not reading bugmail)
: 530312 (view as bug list)
Depends on:
Blocks: 147423
 
 
Reported: 2008-04-17 12:42 UTC by Diego Escalante Urrelo (not reading bugmail)
Modified: 2009-12-20 03:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
20080417_bgo_528559_blocking.diff: Implements a treeview with lsof (6.55 KB, patch)
2008-04-17 12:43 UTC, Diego Escalante Urrelo (not reading bugmail)
none Details | Review
How it looks (16.37 KB, image/png)
2008-04-17 12:44 UTC, Diego Escalante Urrelo (not reading bugmail)
  Details

Description Diego Escalante Urrelo (not reading bugmail) 2008-04-17 12:42:51 UTC
Attaching a draft patch using lsof, it needs to test if lsof call failed among other things missing.
Comment 1 Diego Escalante Urrelo (not reading bugmail) 2008-04-17 12:43:32 UTC
Created attachment 109416 [details] [review]
20080417_bgo_528559_blocking.diff: Implements a treeview with lsof

:)
Comment 2 Diego Escalante Urrelo (not reading bugmail) 2008-04-17 12:44:41 UTC
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.
Comment 3 David Zeuthen (not reading bugmail) 2008-04-17 16:24:35 UTC
This is definitely very interesting, thanks for hacking on this. I'll have a look at the patch later tonight.
Comment 4 Federico Mena Quintero 2008-04-17 17:33:58 UTC
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 :)
Comment 5 David Zeuthen (not reading bugmail) 2008-04-17 17:41:18 UTC
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?
Comment 6 Diego Escalante Urrelo (not reading bugmail) 2008-04-17 20:34:58 UTC
(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.
Comment 7 David Zeuthen (not reading bugmail) 2008-04-28 14:46:34 UTC
*** Bug 530312 has been marked as a duplicate of this bug. ***
Comment 8 David Zeuthen (not reading bugmail) 2008-06-08 01:12:17 UTC
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.

Comment 9 Diego Escalante Urrelo (not reading bugmail) 2008-06-08 01:22:56 UTC
Oh, nevermind then :p.
Comment 10 Milan Bouchet-Valat 2008-06-08 21:15:00 UTC
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.
Comment 11 Mike Rooney 2008-07-09 18:39:36 UTC
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!
Comment 12 peter.hoogkamer 2008-10-31 14:17:30 UTC
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.
 
Comment 13 Diego Escalante Urrelo (not reading bugmail) 2009-12-19 23:12:26 UTC
So this was done in gdu extension for nautilus I think. So, obsolete.