| Summary: | Display name of process which blocks umount / eject | ||
|---|---|---|---|
| Product: | [Unmaintained] solid | Reporter: | william heyland <wh> |
| Component: | libsolid-hal | Assignee: | Alberto Villa <avilla> |
| Status: | RESOLVED FIXED | ||
| Severity: | wishlist | CC: | finex, martin.nad89, rikratva, simonandric5, vortex |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | http://commits.kde.org/plasma-workspace/d64719de4bf824b40cfe43965f09f8ac74605072 | Version Fixed In: | |
| Sentry Crash Report: | |||
*** This bug has been confirmed by popular vote. *** Ok, where's my beer? this is a suggested solution to problems like in BR#78322, though i personally believe it to be limited to the point of being not useful (e.g. would lead to data loss, does not take into consideration multiple documents open in the same process, etc) ... i'd prefer to see a way to signal desktop apps that they need to relinquish file handles open under a given path and give each an opportunity to deal with it gracefully (with an eventual time out and forceable kill if the user OK's it) ... in any case, this belongs with BR#78322 ... *** This bug has been marked as a duplicate of 78322 *** I agree with Aaron J. Seigo's comment above... but think that this is a more general/broad issue that effects linux desktops in general. The association with bug 78322 is ambiguous. Siego's idea of signaling the applications is a great one. The signaling would be very helpfull and save the user from having to search their desktop for the applications that block the umount(). Currently gnome does this with nautilus. If you attempt to umount() a disk under gnome then the nautilus windows browsing the filesystem will automaticly be closed. I am not familiar with the implementation but something similiar could be adopted accross the desktop. Although the nautilus windows are automaticaly closed, the default behaviour of a word processor could be to popup a window offering the user to save or close a particular file. The actual behaviour of an application receiving the signal will differ. The signals to applications via the upcomming dbus IPC mechanism could be a good portable solution. But there would still be instances where a umount would fail due to non dbus or non gui applications. In these cases the user could be notified which application is blocking the umount and be given possible solutions to the block. I agree it's probably not the best idea to give the user the option of killing a process with files open on the device, but it would be extremely helpful just to know which application has files open there. So your dialog would look like: Device can not be safely removed because the application "Amarok" has files open on the device. Please close Amarok and try again. Even though I'm not a linux novice, I still often run into problems with unmounting drives, and then have to randomly exit applications until I've found the culprit On Tuesday 10 May 2005 09:04, Leo Spalteholz wrote: > ------- I agree it's probably not the best idea to give the user the option > of killing a process with files open on the device, but it would be > extremely helpful just to know which application has files open there. So > your dialog would look like: > > Device can not be safely removed because the application "Amarok" has files > open on the device. Please close Amarok and try again. Excellent proposal, I second this. Actually, this might not be possible. Right now for example, I've got my usb thumb drive mounted (under /home/leo/usb), and it won't unmount because the device is busy. A "lsof | grep usb" shows: famd 3551 leo 248r DIR 8,1 16384 1 /home/leo/usb But the real culprit is amarok (which is odd, because I don't have any music on the thumb drive). In any case, telling a user that the application "famd" is blocking the unmount is not particularly usefull. Is there another way to find out which application is blocking the unmount? *** Bug 106848 has been marked as a duplicate of this bug. *** I think this bug has actually be solved. KDE 3.5.5, Debian sid, when I try to unmount a busy drive, it pops up a dialog saying:
Unfortunately, the device system:/media/sda1 (/dev/sda1) named 'System' and currently mounted at /media/System could not be unmounted. Unmounting failed due to the following error:
Device is Busy:
Moreover, programs still using the device have been detected. They are listed below. You have to close them or change their working directory before attempting to unmount the device again.
USER PID ACCESS COMMAND
/media/System: root 13502 f.... wxvlc
This is more or less what I need to solve the problem. That dialog is pretty horrendous though. A normal user isn't going to get past the first sentence.
Something like this would be better:
The device named "System" could not be safely removed because there are still programs using the device. Please exit the programs listed below and try unmounting the drive again.
COMMAND OWNER PID
wxvlc leo 13052
This isn't perfect, but is a lot clearer than the original error message. It could be improved further by removing the need for the word "unmount" which people may not understand. Also the programs using the device should probably be mentioned in the sentence instead of listed in a table (especially if there is only one).
All that other information is useless most of the time. Hide it in a "Technical Details" button or something.
*** Bug 204696 has been marked as a duplicate of this bug. *** And now with 4.x this feature is missing again, as evidenced by the duplicate which just got filed. ;-) Moved to solid which should be a more appropriate component on KDE 4. *** Bug 204201 has been marked as a duplicate of this bug. *** This bug is reported on libsolid which is the kdelibs4 version of the solid library. It is now in maintenance mode. If you think it should still be fixed in the KDE Frameworks 5 version of solid please move it to or report a bug on frameworks-solid. Git commit d64719de4bf824b40cfe43965f09f8ac74605072 by Igor Poboiko. Committed on 17/10/2015 at 19:12. Pushed by poboiko into branch 'master'. Display which process blocks unmount/eject in a plasmoid notification REVIEW: 125248 M +1 -0 dataengines/devicenotifications/CMakeLists.txt M +74 -4 dataengines/devicenotifications/ksolidnotify.cpp M +2 -0 dataengines/devicenotifications/ksolidnotify.h http://commits.kde.org/plasma-workspace/d64719de4bf824b40cfe43965f09f8ac74605072 |
Version: (using KDE KDE 3.3.2) Installed from: Gentoo Packages OS: Linux Hello to all you kde users and developers I have had an idea that will make kde more user friendly when working with removable media. The problem: From my experience using kde I have found that working with removable can sometimes be a pain and never works 100% reliably. The problem occurs when a umount() fails because of 'device is busy' errors (one or more processes are accessing files on the filesystem being unmounted). This is a common problem that can only be solved by 'getting dirty with the command line'. I have spoken to the linux kernel guys and they said that userspace tools should provide the sort of 'clean up' functionality required for gui desktop usage. the problem occurs relatively frequently with day to day desktop usage. For newbie desktop users it can be daunting and scary... The solution: KDE needs an 'intelligent umount() policy' that when 'device is busy' errors occur it pops up a nice window with details of the apps blocking the umount(). Kde should give the user trying to umount() the media various options to solve the filesystem block. The user should have (at a minimum) the options 'would you like to kill/terminate this application?' and 'view information about offending app'. If you couple the new media:/ ioslave with an 'intelligent umount() policy' then working with removable media under kde would be far more user friendly than it currently is. Kind regards William heyland I love kde! you guys rock!