Obviously the unmounting of USB drives is completely broken; often the system will not allow unmounting with no clues as to what application is preventing it. (This is equally bad on both Windows and Mac. Really: Data "may have" been lost? HAS IS OR HASN'T IT!)
Here are some use-cases for the behaviour I would like to see after a drive is forcibly removed, which would remove the need for manual unmounting. These resemble what used to happen with floppy disks.
1. Text editor opens file on USB stick (read-only or read-write). The application is not currently reading or writing (There is no uncommitted data). The USB stick is physically removed without unmounting.
No error dialogs or bubbles appear. When the application next tries to read the file, a dialog is shown: "Text editor is trying to [read from|write to] unmounted file system: ". The user has the option to replace the USB stick and everything carries on as normal. If the user clicks "abort" then the application gets a file I/O error as normal.
2. Text editor has file open and has written to the USB stick, but the data is not yet committed to the disk. The USB stick is physically removed.
A dialog is shown: "File write by Text Editor has failed due to removal of drive. Data will be lost unless you reinsert the drive: ". If the user reinserts the USB stick and clicks retry, it works. If the user clicks abort, the application receives an IO error as normal.
3. XTerm's current directory is on the USB stick. The USB stick is physically removed.
No error dialogs or bubbles appear. The next command to be typed at the shell receives an error (not a GUI dialog, but in the shell). If the USB stick is reinserted and the command retried, it works.
Tags:
(none)
