Bug 270703

Summary: Device notifier needs to let user know if unmount has not completed
Product: [Unmaintained] solid Reporter: ben chang <bchang>
Component: libsolidAssignee: Plasma Bugs List <plasma-bugs>
Status: RESOLVED DUPLICATE    
Severity: major CC: aidanamarks, andreas_nordal_4, bugs.kde.org.onion358, kunguz, sven.burmeister, wilderkde
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Ubuntu   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description ben chang 2011-04-11 19:28:28 UTC
Version:           unspecified (using KDE 4.5.1) 
OS:                Linux

In general, unmounting a removable device such as an external USB drive through Device Notifier unmounts it easily and cleanly.  However, if an operation is still cached, such as a lengthy write, it may take some time before the unmount completes.  There is no notification that the unmount has NOT completed, other than small italic text saying "unmounting..." under the listing for the device if the user opens the Device Notifier again.  It's very easy for the user to mistakenly believe that the unmount has finished, and unplug their device with disastrous consequences. 



Reproducible: Sometimes

Steps to Reproduce:
Attach an external USB drive
Copy files to it
After the copy operation has completed, unmount the drive from Device Notifier by clicking the "Eject" button next to it in the list.


Actual Results:  
Device Notifier closed, as it usually does, suggesting that the umount was complete.  

It wasn't.  Cached writes were still going on in the background from the previous copy operation.  

The drive is formatted HFS+, unjournaled so I can use it in Linux as well as OSX.  

The extents tree has been demolished, Disk Utility and fsck are unable to repair it. 

Expected Results:  
Kept a notification onscreen that the umount had not yet completed.

Everybody knows not to unplug a drive without cleanly unmounting it.  But we have to rely on the desktop to be let us know if unmounting has failed or is still in progress.  In most day-to-day computer usage, operations can happen asynchronously, fail quietly in the background, and notify the user unobtrusively or only on request.  For example, if I try to send an email or load a web page and it fails due to a network error, the only consequence is that I may have to repeat the action.  If I try to copy files to a device but run out of space, I still have the originals.  This is one unusual situation where the user's situational awareness of whether an operation has completed has severe consequences in the form of catastrophic data loss.  

I know requesting "Major" for severity might seem like overkill, or wrong for something that's arguably user error - but I think it's a case where just a small bit of software design can help prevent a very large amount of serious user error.
Comment 1 Jacopo De Simoi 2011-04-13 15:21:25 UTC
This has been on my todo list for quite some time; and btw the Major tag is fine with me. 
The underlying technical issue is not that trivial, however, so I couldn't find a proper solution so far. But I do keep thinking about it, so stay tuned

Thanks
 __J
Comment 2 Jacopo De Simoi 2011-04-13 15:21:34 UTC
This has been on my todo list for quite some time; and btw the Major tag is fine with me. 
The underlying technical issue is not that trivial, however, so I couldn't find a proper solution so far. But I do keep thinking about it, so stay tuned

Thanks
 __J
Comment 3 Jacopo De Simoi 2011-05-23 22:07:06 UTC
I actually misread the report the first time; this is really not that major:
- first of all the device notifier does not close while unmounting and you can quite clearly see that there's something going on.
- second, if such a notification should be present, then it should be there also when unmounting a device in other ways (i.e. with dolphin or via the solid runner), so it should be dealt with by solid itself.
Comment 4 Jacopo De Simoi 2011-08-07 11:22:27 UTC
I finally decided on putting a "major" tag to this issue.
I really hope to find some time to fix it…
Comment 5 Jacopo De Simoi 2011-08-08 06:04:58 UTC
*** Bug 279564 has been marked as a duplicate of this bug. ***
Comment 6 Andreas Nordal 2012-01-25 00:23:56 UTC
Is this a duplicate of bug 192598?
Comment 7 Myriam Schweingruber 2012-09-07 11:29:40 UTC
(In reply to comment #6)
> Is this a duplicate of bug 192598?

Definitely, yes.

*** This bug has been marked as a duplicate of bug 192598 ***