Version: 1.2.1 (using 4.2.3 (KDE 4.2.3), Gentoo) Compiler: i686-pc-linux-gnu-gcc OS: Linux (i686) release 2.6.30-rc2-zen0-IBM-T43-08372-gb1961bf-dirty When a mounted usb stick or any other device is being removed safely, this can take some time. (Especially when the device was not mounted with the sync option). While the umounting takes progress, there is no user feedback. So most user will think that the computer is not progressing their request. There should be a busy sign or something on the device icon until it is safely umounted.
Even worse, if the unmount does not succeed within a timeout (I think it's 30 seconds) dolphin will simply display a cryptic error message saying something like "Operation timed out: did not receive a reply". This is very confusing as it does not explain at all why the device cannot be removed yet (usually there is data still being written to it). Gnome displays a nice notification that there is "data still being written to the removable device" and it thus cannot be removed at present. Would be nice if KDE could display something like that as well. Please tell the user to "please be patient a wait a few moments" instead of showing confusing error messages.
@Kevin: Is this something that must be handled by the application or should this be done on lower layers already?
Well, the report is two fold: 1) The "on-going operation" display is missing and IMO it's responsibility of the application to do that. 2) The "cryptic error message on D-Bus timeout" one would be more for lower levels... not easy to solve though. Claiming "data still being written to the removable device" on the D-Bus timeout is kind of a wild assumption IMO, that's probably what we'll end up doing as we have no more precise info coming back from the system. (2) should definitely be a different BR though, for solid/libsolid component. If someone could care enough to open it that'd be great (ENOTIME for doing it right now and I'll prolly forget later).
Reported as separate bug #204201
Looks like bug 195044 has a proposed solution for this not to happen in the first place.
Resetting assignee to default as per bug #305719
*** Bug 270703 has been marked as a duplicate of this bug. ***
Duplicate of https://bugs.kde.org/show_bug.cgi?id=187615, which is now resolved. *** This bug has been marked as a duplicate of bug 187615 ***