[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: usb flash drive removal (Re: Desktop NetBSD needs your help)
On Mon, Feb 09, 2009 at 11:57:01AM -0500, Arnaud Lacombe wrote:
> On Mon, Feb 9, 2009 at 11:33 AM, Eric Haszlakiewicz
> <erh%nimenees.com@localhost> wrote:
> > On Mon, Feb 09, 2009 at 10:51:32AM -0500, Arnaud Lacombe wrote:
> >> Hi,
> >> On Mon, Feb 9, 2009 at 10:33 AM, Eric Haszlakiewicz
> >> <erh%nimenees.com@localhost> wrote:
> >> > I think that there should not _be_ a wrong time to remove a USB drive.
> >> > Yes, it may be hard to implement it in NetBSD, but it is entirely
> >> > possible
> >> > to have a system that doesn't crash, and even does something reasonable.
> >> > (e.g. like providing an api for prompting the user to reattach the
> >> > device)
> >> >
> >> You cannot ensure that the device is the same state than previously.
> >> You cannot even ensure that the newly plugged device is the same that
> >> the old one. The only sane thing to do is to clean-up everything.
> > No, you're wrong. You CAN ensure, with a reasonably high degree of
> > certainty,
> > that the device is the same as the old one.
> Sorry to say that, but if it's not 100% of certainty you won't go far.
Well you can keep feeling sorry for yourself, but I know that you don't
need 100% certainty to make the user experience better.
> > Do all of the following:
> > 1) A device is unplugged
> > a) If there is no unwritten data cached, gracefully unmount the device and
> > revoke any open file descriptors when the device is unplugged.
> > b) If there _is_ data cached, keep the mount around in a suspended state,
> > saving information about the device and in-flight data until later.
> > b.i) Issue an event that alerts the user that he should plug the device
> > back in.
> > 2) When a device is reattached
> > a) If the device has a dependable hardware id of some kind, compare that
> > with what the previous id was.
> in the mean time, I took a picture with my camera/got a phone call,
> the file-system on the device changed, you replug-it, things are not
> as they used to be... and boom! There is billion reasons for a device
> to alter its file-system while it is supposedly doing nothing. In the
> best case, we crash, in the worst case, we corrupt the remote
And that is exactly why the user needs to be ASKED whether to use the cached
data or not. Is that really so difficult of a thing to understand?
If you change the data on the device, and then say that it's ok to use,
well too bad if things get messed up. BUT, if you know that it hasn't
changed, perhaps because you unplugged it by accident, or so you could
pick your laptop up and carry it to a different desk, the OS should let
(also, I certainly don't consider "we crash" to be the "best case".)
> file-system. Not speaking that you'll need to keep track of every
> possible unique ID that can exist, good luck.
You don't need to keep track of every id that can exists, only those that
have been used on your machine.
Main Index |
Thread Index |