One Hundred Papercuts

Bug #28835
Comment #27

Comment 27 for bug 28835

Revision history for this message

Emmet Hikory (persia) wrote on 2009-06-12:

#27

The trick with just removing media without warning the system is the data write cache, such that users randomly pulling a USB drive without unmounting may well have not fully flushed all the writes (the "Not safe to remove" bit). Perhaps rather than having an explicit unmount/eject feature, the UI should inform the user during the times that it is unsafe to remove the device, and allow/encourage unsupervised removal at all other times. An example of such mitigation would be ltspfs (although that also involves network mounting), although this doesn't currently have any means of notifying the user during the short periods it is unsafe to remove the device and carries some performance penalties.

The next trick is determining when to present the user with a means to start navigating to known paths, which might involve the creation of an access icon on hardware detection, left present until hardware detection of removal. This works less well for optical drives without hardware sense, and doesn't work at all for network resources, but should cover other cases (USB, firewire, MMC, etc.). If access is unavailable to a resource when the user attempts to use it, the user could be presented with some dialog that could help resolve it (Please insert the disc "foo" (OK retries, Cancel stops the access attempt)) or (Please check your network connect tio resource "bar" (same options)).

At that point, it perhaps becomes interesting to have a means to remove access icons for mitigated access, which should be amenable to discoverable text (e.g. "Remove me"). This could apply to network connection or unsensed optical media links where the user no longer has a need for immediate access (although there may be leftover links in Places to allow easy restoration of removed access icons). It could also apply to sensed USB/MMC/etc. devices where the user *intentionally* doesn't want to see it. New access icons would be created on new plug events (although there would need to be some UI to detect the contents of unsensed optical drives: perhaps just a generic link in Places).

Note that the effects of raw device access (my previous use cases A, B) may confuse a system with that degree of automation support: *lots* of testing is encouraged. More complex credential caching would be required to cover encrypted devices (previous use case C), and the user would need some UI to clear the credential cache (maybe useful anyway, for other classes of cached credentials). I'm not sure these problems are any easier than those raised in the "mount/unmount" model for the same use cases, but I am sure that there exist lots of other possible models for users to interact with removable/transient/remote media beyond simply copying what is seen elsewhere in the name of discoverability.

The trick with just removing media without warning the system is the data write cache, such that users randomly pulling a USB drive without unmounting may well have not fully flushed all the writes (the "Not safe to remove" bit).  Perhaps rather than having an explicit unmount/eject feature, the UI should inform the user during the times that it is unsafe to remove the device, and allow/encourage unsupervised removal at all other times.  An example of such mitigation would be ltspfs (although that also involves network mounting), although this doesn't currently have any means of notifying the user during the short periods it is unsafe to remove the device and carries some performance penalties.

The next trick is determining when to present the user with a means to start navigating to known paths, which might involve the creation of an access icon on hardware detection, left present until hardware detection of removal.  This works less well for optical drives without hardware sense, and doesn't work at all for network resources, but should cover other cases (USB, firewire, MMC, etc.).  If access is unavailable to a resource when the user attempts to use it, the user could be presented with some dialog that could help resolve it (Please insert the disc "foo" (OK retries, Cancel stops the access attempt)) or (Please check your network connect tio resource "bar" (same options)).

At that point, it perhaps becomes interesting to have a means to remove access icons for mitigated access, which should be amenable to discoverable text (e.g. "Remove me").  This could apply to network connection or unsensed optical media links where the user no longer has a need for immediate access (although there may be leftover links in Places to allow easy restoration of removed access icons).  It could also apply to sensed USB/MMC/etc. devices where the user *intentionally* doesn't want to see it.  New access icons would be created on new plug events (although there would need to be some UI to detect the contents of unsensed optical drives: perhaps just a generic link in Places).

Note that the effects of raw device access (my previous use cases A, B) may confuse a system with that degree of automation support: *lots* of testing is encouraged.  More complex credential caching would be required to cover encrypted devices (previous use case C), and the user would need some UI to clear the credential cache (maybe useful anyway, for other classes of cached credentials).  I'm not sure these problems are any easier than those raised in the "mount/unmount" model for the same use cases, but I am sure that there exist lots of other possible models for users to interact with removable/transient/remote media beyond simply copying what is seen elsewhere in the name of discoverability.