Hi,
we've got a bug report about the mishandling of DVD/CDROM media eject
button, and it seems indeed broken since some time ago. In short:
when the eject button is pressed, the media is forcibly ejected no
matter whether it's mounted or in use. And, the mount remains even
after ejecting the media, eventually the kernel spews error messages
when the further access happens.
There seem many problems behind the scene. First of all, udev tries
to lock the media unconditionally at the media insert. This seems to
be a workaround for making DISK_EVENT_EJECT_REQUEST working. Then,
udev unlocks the media and issues the SCSI eject ioctl unconditionally
when DISK_EVENT_EJECT_REQUEST event is received. Since SCSI ioctl
doesn't take the open refcount into account, it results in the
forcible eject.
(A relevant problem is that CDROM_IOCTL doesn't behave consistently;
it checks the open refcount only for IDE. For SCSI, it bypasses and
gives the control directly to SCSI backend. So, using CDROM_EJECT
ioctl won't help as of now.)
I thought that fixing the udev behavior would solve the problem. But
it turned out that I was too naive. A bigger problem is that all
user-space stuff misinterprets DISK_EVENT_EJECT_REQUEST event: they
see this as if the disk is *ready* to be ejected. KDE, for example,
dismisses the DVD icon when it receives this event even if it's still
mounted.
I can think of a few possible solutions, but all imperfect.
A. As a short-cut solution, filter out DISK_EVENT_EJECT_REQUEST in
drivers/block/cdrom.c when the device is in use (the patch below).
This avoids the misbehavior, obviously, at least. But it also
misses the events if the user-space really expects the eject button
press state.
B. Fix the kernel media polling to work without explicit media lock,
remove udev hackish workarounds. *In addition* fix all misuses of
DISK_EVENT_EJECT_REQUESTEd in the desktop scenes.
C. Fix CDROM_EJECT incompatible behavior so that udev helper can use
CDROM_EJECT instead of SCSI eject command, and relock the media if
the eject fails. And, fix all misuses of
DISK_EVENT_EJECT_REQUESTED in the desktop scenes as well.
Do you guys have any better / feasible solution in mind?
thanks,
Takashi
---
diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
index 5d28a45d2960..03c073eb5396 100644
--- a/drivers/cdrom/cdrom.c
+++ b/drivers/cdrom/cdrom.c
@@ -294,12 +294,15 @@ static bool lockdoor = 1;
static bool check_media_type;
/* automatically restart mrw format */
static bool mrw_format_restart = 1;
+/* filter out the eject event when the device is being used */
+static bool filter_eject_event = 1;
module_param(debug, bool, 0);
module_param(autoclose, bool, 0);
module_param(autoeject, bool, 0);
module_param(lockdoor, bool, 0);
module_param(check_media_type, bool, 0);
module_param(mrw_format_restart, bool, 0);
+module_param(filter_eject_event, bool, 0);
static DEFINE_MUTEX(cdrom_mutex);
@@ -1477,6 +1480,8 @@ static void cdrom_update_events(struct cdrom_device_info *cdi,
unsigned int events;
events = cdi->ops->check_events(cdi, clearing, CDSL_CURRENT);
+ if (filter_eject_event && cdi->use_count > 0)
+ events &= ~DISK_EVENT_EJECT_REQUEST;
cdi->vfs_events |= events;
cdi->ioctl_events |= events;
}
On Mon, Feb 2, 2015 at 2:20 PM, Takashi Iwai <[email protected]> wrote:
> we've got a bug report about the mishandling of DVD/CDROM media eject
> button, and it seems indeed broken since some time ago. In short:
> when the eject button is pressed, the media is forcibly ejected no
> matter whether it's mounted or in use.
Which is the right thing to do for all read-only stuff.
> And, the mount remains even
> after ejecting the media, eventually the kernel spews error messages
> when the further access happens.
This cosmetic issue should be "fixed" if it matters.
> There seem many problems behind the scene. First of all, udev tries
> to lock the media unconditionally at the media insert. This seems to
> be a workaround for making DISK_EVENT_EJECT_REQUEST working.
It is no workaround, it's the SCSI spec. You only see events if you
lock the door.
> Then,
> udev unlocks the media and issues the SCSI eject ioctl unconditionally
> when DISK_EVENT_EJECT_REQUEST event is received. Since SCSI ioctl
> doesn't take the open refcount into account, it results in the
> forcible eject.
Which again is the expected behavior in the user's view.
> (A relevant problem is that CDROM_IOCTL doesn't behave consistently;
> it checks the open refcount only for IDE. For SCSI, it bypasses and
> gives the control directly to SCSI backend. So, using CDROM_EJECT
> ioctl won't help as of now.)
>
> I thought that fixing the udev behavior would solve the problem. But
> it turned out that I was too naive. A bigger problem is that all
> user-space stuff misinterprets DISK_EVENT_EJECT_REQUEST event: they
> see this as if the disk is *ready* to be ejected. KDE, for example,
> dismisses the DVD icon when it receives this event even if it's still
> mounted.
It is not really about being "ready to eject", if the user presses the
button, the user does not want to wait for anything else than actually
ejecting the media as fast as possible. It is the same as ripping out
a USB cable. It needs to work, no matter if things are mounted or
busy.
We have to handle "the mess" in our tools, meaning cleaning up the stale
stuff in the kernel or userspace, just like we do with all other
plugable devices when they ripped out by the user.
I'm really not convinced that suppressing events here makes any sense.
It is just a hardware button event which should not be masked out for
rather weird reasons.
Thanks,
Kay
On Mon, 2 Feb 2015, Kay Sievers wrote:
> > I thought that fixing the udev behavior would solve the problem. But
> > it turned out that I was too naive. A bigger problem is that all
> > user-space stuff misinterprets DISK_EVENT_EJECT_REQUEST event: they
> > see this as if the disk is *ready* to be ejected. KDE, for example,
> > dismisses the DVD icon when it receives this event even if it's still
> > mounted.
>
> It is not really about being "ready to eject", if the user presses the
> button, the user does not want to wait for anything else than actually
> ejecting the media as fast as possible. It is the same as ripping out
> a USB cable. It needs to work, no matter if things are mounted or
> busy.
All the technical details aside, this is a bold statement -- how do you
know what the user actually wants?
I for one want to see the medium locked if in use, just as it has been
since 1990s. If I wanted to do an emergency eject (the equivalent of
ripping out a USB cable), then I would use a paperclip in the manual eject
hole. So you've got a counterexample to your assertion now. All people
are not the same.
All I want to say here is there seems to be a policy hidden somewhere
here where it should not. It's up to the user to decide what suits him or
her. We just need to give them the right tools.
> It is just a hardware button event which should not be masked out for
> rather weird reasons.
Precisely, and I should have a way to control it. If I used a GUI, I
might want the event to pop up a window with the list of current users
(accessing processes) of the device, perhaps asking if to terminate them.
Or flip a relay to make my kettle boil water.
FWIW,
Maciej
On Mon, Feb 2, 2015 at 8:34 PM, Maciej W. Rozycki <[email protected]> wrote:
> On Mon, 2 Feb 2015, Kay Sievers wrote:
>
>> > I thought that fixing the udev behavior would solve the problem. But
>> > it turned out that I was too naive. A bigger problem is that all
>> > user-space stuff misinterprets DISK_EVENT_EJECT_REQUEST event: they
>> > see this as if the disk is *ready* to be ejected. KDE, for example,
>> > dismisses the DVD icon when it receives this event even if it's still
>> > mounted.
>>
>> It is not really about being "ready to eject", if the user presses the
>> button, the user does not want to wait for anything else than actually
>> ejecting the media as fast as possible. It is the same as ripping out
>> a USB cable. It needs to work, no matter if things are mounted or
>> busy.
>
> All the technical details aside, this is a bold statement -- how do you
> know what the user actually wants?
By working with people who spent a lot of time with the questions what
the default behavior of user interfaces should be. Buttons, especially
physical ones, need to give immediate feedback to the user. If they
don't give it it, people will look for something else to get what they
want.
> I for one want to see the medium locked if in use, just as it has been
> since 1990s. If I wanted to do an emergency eject (the equivalent of
> ripping out a USB cable), then I would use a paperclip in the manual eject
> hole. So you've got a counterexample to your assertion now. All people
> are not the same.
It's just the current default setup and intentional behavior. You or
your distribution can for sure implement something else.
Kay
On 2015-02-02 14:34, Maciej W. Rozycki wrote:
> On Mon, 2 Feb 2015, Kay Sievers wrote:
>
>>> I thought that fixing the udev behavior would solve the problem. But
>>> it turned out that I was too naive. A bigger problem is that all
>>> user-space stuff misinterprets DISK_EVENT_EJECT_REQUEST event: they
>>> see this as if the disk is *ready* to be ejected. KDE, for example,
>>> dismisses the DVD icon when it receives this event even if it's still
>>> mounted.
>>
>> It is not really about being "ready to eject", if the user presses the
>> button, the user does not want to wait for anything else than actually
>> ejecting the media as fast as possible. It is the same as ripping out
>> a USB cable. It needs to work, no matter if things are mounted or
>> busy.
>
> All the technical details aside, this is a bold statement -- how do you
> know what the user actually wants?
>
> I for one want to see the medium locked if in use, just as it has been
> since 1990s. If I wanted to do an emergency eject (the equivalent of
> ripping out a USB cable), then I would use a paperclip in the manual eject
> hole. So you've got a counterexample to your assertion now. All people
> are not the same.
>
> All I want to say here is there seems to be a policy hidden somewhere
> here where it should not. It's up to the user to decide what suits him or
> her. We just need to give them the right tools.
>
>> It is just a hardware button event which should not be masked out for
>> rather weird reasons.
>
> Precisely, and I should have a way to control it. If I used a GUI, I
> might want the event to pop up a window with the list of current users
> (accessing processes) of the device, perhaps asking if to terminate them.
> Or flip a relay to make my kettle boil water.
I agree, there should be some option to control this, although
personally, I would prefer two options, one for when it's read-only (in
which case I would prefer the current behavior), and one for when it's
read-write (in which case, I would prefer that the door-lock be engaged).
Also, udev's current response isn't all that great either, when it get's
the event, it should do a lazy unmount of the device. Windows and OS X
automatically unmount filesystems from ejected media, so it is expected
behavior for many users (and I keep meaning to open a bug against udev
because of this, but keep forgetting).
The fact that it stays mounted can cause all kinds of confusing issues
as well if the user inserts a different disc; I've seen cases (recently
in fact) where a new disc was inserted and due to caching, it showed
dentries from the old disc, but with the files full of gibberish, and it
refused to unmount the (now invalid) filesystem without using umount -f
(which shouldn't be needed for a read-only FS, period).
On Monday 02 February 2015 21:02:23 Austin S Hemmelgarn wrote:
> On 2015-02-02 14:34, Maciej W. Rozycki wrote:
> > On Mon, 2 Feb 2015, Kay Sievers wrote:
> >>> I thought that fixing the udev behavior would solve the problem. But
> >>> it turned out that I was too naive. A bigger problem is that all
> >>> user-space stuff misinterprets DISK_EVENT_EJECT_REQUEST event: they
> >>> see this as if the disk is *ready* to be ejected. KDE, for example,
> >>> dismisses the DVD icon when it receives this event even if it's still
> >>> mounted.
> >>
> >> It is not really about being "ready to eject", if the user presses the
> >> button, the user does not want to wait for anything else than actually
> >> ejecting the media as fast as possible. It is the same as ripping out
> >> a USB cable. It needs to work, no matter if things are mounted or
> >> busy.
> >
> > All the technical details aside, this is a bold statement -- how do you
> > know what the user actually wants?
> >
> > I for one want to see the medium locked if in use, just as it has been
> > since 1990s. If I wanted to do an emergency eject (the equivalent of
> > ripping out a USB cable), then I would use a paperclip in the manual
> > eject hole. So you've got a counterexample to your assertion now. All
> > people are not the same.
> >
> > All I want to say here is there seems to be a policy hidden somewhere
> > here where it should not. It's up to the user to decide what suits him
> > or her. We just need to give them the right tools.
> >
> >> It is just a hardware button event which should not be masked out for
> >> rather weird reasons.
> >
> > Precisely, and I should have a way to control it. If I used a GUI, I
> > might want the event to pop up a window with the list of current users
> > (accessing processes) of the device, perhaps asking if to terminate them.
> > Or flip a relay to make my kettle boil water.
>
> I agree, there should be some option to control this, although
> personally, I would prefer two options, one for when it's read-only (in
> which case I would prefer the current behavior), and one for when it's
> read-write (in which case, I would prefer that the door-lock be engaged).
>
> Also, udev's current response isn't all that great either, when it get's
> the event, it should do a lazy unmount of the device. Windows and OS X
> automatically unmount filesystems from ejected media, so it is expected
> behavior for many users (and I keep meaning to open a bug against udev
> because of this, but keep forgetting).
>
> The fact that it stays mounted can cause all kinds of confusing issues
> as well if the user inserts a different disc; I've seen cases (recently
> in fact) where a new disc was inserted and due to caching, it showed
> dentries from the old disc, but with the files full of gibberish, and it
> refused to unmount the (now invalid) filesystem without using umount -f
> (which shouldn't be needed for a read-only FS, period).
At least Windows Me can do this with some CD/DVD drives:
If the eject button is pressed and a file is open from the CD, a dialog pops
up if you really want to eject the CD. If you click OK, the CD is ejected and
filesystem forcibly unmounted (programs running off the CD will crash). If
you click no, nothing happens.
If there's no file open from the CD, it simply ejects.
It worked with my Toshiba DVD drive but not (older) Toshiba CD drive - it
always ejected the CD. Looks like some drives can report eject button press
when locked and some can't.
--
Ondrej Zary
On Mon, 2 Feb 2015, Kay Sievers wrote:
> > All the technical details aside, this is a bold statement -- how do you
> > know what the user actually wants?
>
> By working with people who spent a lot of time with the questions what
> the default behavior of user interfaces should be. Buttons, especially
> physical ones, need to give immediate feedback to the user. If they
> don't give it it, people will look for something else to get what they
> want.
It still covers a group of people only, not all of them. A UI is a
convention, there may be different ones. There is little if anything more
frustrating in interacting with computers than an UI that "knows better"
what I want to do than I do, with no way to override the built-in logic.
I am not a statistical sample, I am an individual with my own preferences.
I have suffered from such built-in assumptions myself and I talked many
times to people who complained about them too.
> > I for one want to see the medium locked if in use, just as it has been
> > since 1990s. If I wanted to do an emergency eject (the equivalent of
> > ripping out a USB cable), then I would use a paperclip in the manual eject
> > hole. So you've got a counterexample to your assertion now. All people
> > are not the same.
>
> It's just the current default setup and intentional behavior. You or
> your distribution can for sure implement something else.
Fair enough, but if this is a matter of decisions made by a distribution,
then why is this an issue raised on LKML? What does it have to do with
the kernel or why does it have to be addressed in the kernel, one way or
another? Or does it indeed?
Maciej
On Mon, 2015-02-02 at 20:45 +0100, Kay Sievers wrote:
> > All the technical details aside, this is a bold statement -- how do
> you
> > know what the user actually wants?
>
> By working with people who spent a lot of time with the questions what
> the default behavior of user interfaces should be. Buttons, especially
> physical ones, need to give immediate feedback to the user. If they
> don't give it it, people will look for something else to get what they
> want.
Nevertheless this is a policy decision and doesn't belong into udev.
Regards
Oliver
At Mon, 2 Feb 2015 20:03:05 +0100,
Kay Sievers wrote:
>
> On Mon, Feb 2, 2015 at 2:20 PM, Takashi Iwai <[email protected]> wrote:
> > we've got a bug report about the mishandling of DVD/CDROM media eject
> > button, and it seems indeed broken since some time ago. In short:
> > when the eject button is pressed, the media is forcibly ejected no
> > matter whether it's mounted or in use.
>
> Which is the right thing to do for all read-only stuff.
Yes, for read-only, it would be OK if it really does it right.
I raised the question because it doesn't do it so right yet (stale
states and no lock capability).
Also, what if the device is not read-only, e.g. during burning CD/DVD
or mounting DVD-RAM? Is the immediate forcible eject still the only
option?
> > And, the mount remains even
> > after ejecting the media, eventually the kernel spews error messages
> > when the further access happens.
>
> This cosmetic issue should be "fixed" if it matters.
>
> > There seem many problems behind the scene. First of all, udev tries
> > to lock the media unconditionally at the media insert. This seems to
> > be a workaround for making DISK_EVENT_EJECT_REQUEST working.
>
> It is no workaround, it's the SCSI spec. You only see events if you
> lock the door.
Yeah, I do understand the reason behind it. But: why udev has to take
care of SCSI implementation details at this place at all? Isn't the
place for the generic cdrom device? If it's only for obtaining the
eject events, you're essentially working around the problem. Instead,
the kernel should have provided a saner way to enable the event
generation, IMO.
The worst point in the current udev rule implementation is that we
lose the tray lock functionality effectively since the udev rule lock
and unlock unconditionally.
> > Then,
> > udev unlocks the media and issues the SCSI eject ioctl unconditionally
> > when DISK_EVENT_EJECT_REQUEST event is received. Since SCSI ioctl
> > doesn't take the open refcount into account, it results in the
> > forcible eject.
>
> Which again is the expected behavior in the user's view.
What if user doesn't want? e.g. DVD/CD media is being burned?
> > (A relevant problem is that CDROM_IOCTL doesn't behave consistently;
> > it checks the open refcount only for IDE. For SCSI, it bypasses and
> > gives the control directly to SCSI backend. So, using CDROM_EJECT
> > ioctl won't help as of now.)
> >
> > I thought that fixing the udev behavior would solve the problem. But
> > it turned out that I was too naive. A bigger problem is that all
> > user-space stuff misinterprets DISK_EVENT_EJECT_REQUEST event: they
> > see this as if the disk is *ready* to be ejected. KDE, for example,
> > dismisses the DVD icon when it receives this event even if it's still
> > mounted.
>
> It is not really about being "ready to eject", if the user presses the
> button, the user does not want to wait for anything else than actually
> ejecting the media as fast as possible. It is the same as ripping out
> a USB cable. It needs to work, no matter if things are mounted or
> busy.
Well, it's not quite analogous with USB disconnection, since the
handling of the eject button is a software issue. From that POV, it's
rather analog to the handling of the power button or the lid switch.
And for such buttons, we do care other things. The system doesn't
forcibly and directly power off when the button is pressed -- even if
only read-only disk is mounted.
Don't get me wrong: for my own purpose, I don't object to the final
behavior, i.e. the immediate eject of media. But there are people who
expect differently (the media shouldn't be ejected while in use), or I
would expect that such behavior policy could be managed in the
desktop. But, no, right now, this is already a fixed policy in the
udev rules, so we can't change it (dynamically or statically) unless
breaking many others. And an important feature like media lock was
dropped completely.
> We have to handle "the mess" in our tools, meaning cleaning up the stale
> stuff in the kernel or userspace, just like we do with all other
> plugable devices when they ripped out by the user.
The cleanup of the stale state is actually trivial, just replacing
cdrom_id --eject with /usr/bin/eject. But, I'm not sure whether doing
such a thing is the best solution.
> I'm really not convinced that suppressing events here makes any sense.
> It is just a hardware button event which should not be masked out for
> rather weird reasons.
Heh, I didn't show the patch as a real proposal at all. Otherwise I'd
have titled as RFC or such. It's a hack like hell and I hate it too.
That said, if we can manage it in a better way, I'd happily take that
approach.
thanks,
Takashi
At Mon, 2 Feb 2015 21:12:34 +0000 (GMT),
Maciej W. Rozycki wrote:
>
> > > I for one want to see the medium locked if in use, just as it has been
> > > since 1990s. If I wanted to do an emergency eject (the equivalent of
> > > ripping out a USB cable), then I would use a paperclip in the manual eject
> > > hole. So you've got a counterexample to your assertion now. All people
> > > are not the same.
> >
> > It's just the current default setup and intentional behavior. You or
> > your distribution can for sure implement something else.
>
> Fair enough, but if this is a matter of decisions made by a distribution,
> then why is this an issue raised on LKML? What does it have to do with
> the kernel or why does it have to be addressed in the kernel, one way or
> another? Or does it indeed?
I originally raised the question to LKML since there are open problems
in the kernel side, too. For example, the eject event can be
generated only when the media is locked. It's a specification of
SCSI, but it doesn't mean that we have to provide only this way.
And, another issue is that DISK_EJECT_REQUESTED event is treated by
all user-space programs as if the device is actually ejected. It's a
misuse in user-space side, so ideally it's no kernel issue. But if
all user-space stuff misuses, it becomes it's right -- no matter what
is the original definition by kernel, I'm afraid.
Also, as already mentioned, the cdrom device ioctl behavior is
inconsistent among SCSI and others.
Takashi
> By working with people who spent a lot of time with the questions what
> the default behavior of user interfaces should be. Buttons, especially
> physical ones, need to give immediate feedback to the user. If they
> don't give it it, people will look for something else to get what they
> want.
So spend a day in a location which isn't full of desktop users. In an
environment where these are systems doing real world work you do not want
to be having CD-ROMs eject because someone pushed the wrong button or
because they bumped one.
Locked media has its place. Your argument about feedback btw sounds rather
like you've not thought it through. Users do want immediate feedback, but
sticking a box on the UI that says "XYZ is currently using the CD-ROM,
eject anyway" is immediate feedback too. Especially when XYZ is things
like "The machine cutting tool" or "The telephone hold music system"
Alan
> > It is no workaround, it's the SCSI spec. You only see events if you
> > lock the door.
>
> Yeah, I do understand the reason behind it. But: why udev has to take
> care of SCSI implementation details at this place at all? Isn't the
> place for the generic cdrom device? If it's only for obtaining the
> eject events, you're essentially working around the problem. Instead,
> the kernel should have provided a saner way to enable the event
> generation, IMO.
You could take that to the SCSI and ATA committee's and then try and get
them to agree and every vendor on the planet to make every crapware USB
device implement it. Good luck.
The kernel can provide only the lowest common denominator of service if
it provides a single unified model. In CD space thats a *very low common
denominator*
> The worst point in the current udev rule implementation is that we
> lose the tray lock functionality effectively since the udev rule lock
> and unlock unconditionally.
So fix udev. The kernel can't invent features the hardware doesn't have
and it certainly can't keep polling a drive as that'll murder the battery.
Alan
On 2015-02-03 07:31, Takashi Iwai wrote:
>>> Then,
>>> udev unlocks the media and issues the SCSI eject ioctl unconditionally
>>> when DISK_EVENT_EJECT_REQUEST event is received. Since SCSI ioctl
>>> doesn't take the open refcount into account, it results in the
>>> forcible eject.
>>
>> Which again is the expected behavior in the user's view.
>
> What if user doesn't want? e.g. DVD/CD media is being burned?
>
FWIW, I have seen some drives where either the hardware or the drive
firmware ignores the eject button while a write operation is in progress
(ie, doesn't appear to even send the event, let alone eject the disk).
At Tue, 3 Feb 2015 13:39:06 +0000,
One Thousand Gnomes wrote:
>
> > > It is no workaround, it's the SCSI spec. You only see events if you
> > > lock the door.
> >
> > Yeah, I do understand the reason behind it. But: why udev has to take
> > care of SCSI implementation details at this place at all? Isn't the
> > place for the generic cdrom device? If it's only for obtaining the
> > eject events, you're essentially working around the problem. Instead,
> > the kernel should have provided a saner way to enable the event
> > generation, IMO.
>
> You could take that to the SCSI and ATA committee's and then try and get
> them to agree and every vendor on the planet to make every crapware USB
> device implement it. Good luck.
>
> The kernel can provide only the lowest common denominator of service if
> it provides a single unified model. In CD space thats a *very low common
> denominator*
I meant the saner way ioctl implementation, not about something about
the new hardware control. Currently, the media lock ioctl is used as
a way to enable the event. So we can't handle the additional media
lock properly since the state is a bool in kernel. If it's a flag
with two bits (one for the media lock and one for the event
enablement), user-space doesn't need to track the state by itself, for
example.
Takashi
On Tue, Feb 03, 2015 at 01:34:32PM +0000, One Thousand Gnomes wrote:
> > By working with people who spent a lot of time with the questions what
> > the default behavior of user interfaces should be. Buttons, especially
> > physical ones, need to give immediate feedback to the user. If they
> > don't give it it, people will look for something else to get what they
> > want.
>
> So spend a day in a location which isn't full of desktop users. In an
> environment where these are systems doing real world work you do not want
> to be having CD-ROMs eject because someone pushed the wrong button or
> because they bumped one.
Even for desktop users, if you said desktop users are using
executables or data files on the removeable storage device, and the
device gets ejected unceremoniously --- even if it was mounted
read-only --- is very likely going to cause the application to crash.
If the user hadn't saved their data before they accidentally bumped
the eject button, the user could be pretty unhappy....
- Ted