On Sat, Feb 14, 2009 at 04:20:40PM -0600, David Young wrote: > > If you say it's acceptable to block before the device is reconnected, > > how do you deal with e.g. the UI notification component which was > > supposed to alert about accidental device unblock hanging on the > > unplugged file system. > > It is acceptable to block access to the device before the device is > reconnected. It seems to me that a UI notification component will only > hang if it uses resources on the very same disconnected device as it > reports on, but this brings us back to my previous question. There's an analogous use-case here to consider. When we suspend the system, it would be great if there was a mechanism to clear cgd(4) keys from memory, suspend IO to the device, and then prompt for keys/passphrase again on resume before unblocking the device. For some use(r)s, it may even be desirable to trigger this by idle time or some other event (screen lock, lid close, special hotkey). It need not be a GUI prompt (perhaps should not), and we have better opportunities to control the timing than an unexpected yanking of the device, but the framework/pattern needed seems much the same. Including the idea that we sync and maybe even power down usb sticks when idle even a briefly, making them safer to yank most of the time, as well as minimising the user delay when they ask to remove/suspend. -- Dan.
Attachment:
pgprzFZKHbhgK.pgp
Description: PGP signature