This is a definitely confirmed bug and we all understand the serious nature of the problem at heart, but it is also a bug that does not have any easy, unintrusive fixes. As a result, it's gonna take some time to find the optimal solution and implement it. Confirming the bug and/or lecturing on the seriousness of this bug any more will just generate more launchpad mail and not add any productiveness.
The problem is, the unmount dialog was lost on migration from KDE handling mounts to KDE asking dbus/HAL to handle mounts. There is not enough information being reported back via this new route to determine when an unmount operation is completely done... just whether or not it was successfully initiated. So, possible workarounds and their drawbacks would be: (1) Make global HAL policy as sync for removable media. This drags all flavors of Ubuntu into this ugly mess and reduces performance all- around, not to mention adding various degrees of additional stress on media due to VFAT's incorrect handling of the sync option. It is unfair to have this affect other flavors of Ubuntu as they are not affected by this KDE-specific bug. (2) Make HAL policy as sync for kubuntu via kubuntu-default-settings. This in my mind is the most straightforward and also easiest to implement workaround until a true fix can be reached, but having a package modify configuration files in /etc is currently taboo (a violation of packaging policy) (3) Extend the dbus/HAL mechanism for unmounting to differentiate between unmountING and unmountED. There may or may not be enough information exported via dbus to deduce that already; I'm not expert in dbus. But I would expect the KDE guys not to have introduced this bug if it was indeed this trivial to fix. (4) Have KDE watch /proc/mounts or a similar mechanism for hackjobbed unmount progress detection, similar to what Ubuntu's GNOME does with its unmount dialog. Time consuming to implement? (5) Have KDE remount read-only then unmount. This ensures that by the time the unmount is executed the medium will be in a written state safe for removal. This is also time-consuming to implement, and also has further complications given that there is currently no mechanism for ordinary users to remount read-only (That takes root), and also adds another failure mode in the read-only stage. If a application opens a file on the read-only disk, it will no longer unmount cleanly, leaving the need to roll back to read-write mount (which again may or may not succeed). This may leave users stuck with a half-crippled half-unmounted state, which is less than optimal to say the least :) -- [Edgy Data Loss] umount progress dialog missing https://launchpad.net/bugs/61946 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
