Bug 120001 - RFE: Auto-eject of removable media is unsafe
Summary: RFE: Auto-eject of removable media is unsafe
Alias: None
Product: Fedora
Classification: Fedora
Component: dvd+rw-tools   
(Show other bugs)
Version: 2
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Harald Hoyer
QA Contact: Brian Brock
Keywords: FutureFeature
Depends On:
TreeView+ depends on / blocked
Reported: 2004-04-05 00:17 UTC by Brian "netdragon" Bober
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-12-08 11:12:02 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Brian "netdragon" Bober 2004-04-05 00:17:54 UTC
Forcing an eject on a user is unsafe.

1453916160/1461780480 (99.5%) @2.5x, remaining 0:02
1457225728/1461780480 (99.7%) @0.7x, remaining 0:01
builtin_dd: 713760*2KB out
/dev/hdd: flushing cache
/dev/hdd: stopping de-icing
/dev/hdd: writing lead-out
/dev/hdd: reloading tray

Please pause before reloading tray and give them a message telling
them you are about to eject it so the user has a chance to prepare for
it. I have an Antec SOHO tower and therefore my computer has a door
covering the drives. These forced ejects make my heart pound, and
eventually either the drive is going to break, or the door from all
these forced ejects. The door won't stay open, either, so I can't
really help it :-)

Comment 1 Harald Hoyer 2004-04-05 08:45:09 UTC
Could you please report this upstream to:
http://fy.chalmers.se/~appro/linux/DVD+RW/ ?? Thx!

Comment 2 Brian "netdragon" Bober 2004-04-05 17:42:28 UTC
I think he's overwhelmed with mail or something because I sent an
email to him a while ago about something else, and never got a reply.
Therefore, I don't know if he got the email about that, and I'll send
him an email, but would like this open until I get a response. If I
don't, maybe someone else can try. The word redhat.com in an email
addy might catch his eye and he might read it sooner. Nowadays, you
never know if spam filters didn't accidentally catch my email.

OTOH, couldn't the kernel have some parameter to put some kind of
message on the screen with a blue screen or something to warn the user
of an eject like:

A program (PID: xxxx name: xxxx) is requesting to eject a removable
media, please open the front door on your computer case and then press
any key.

Comment 3 Harald Hoyer 2004-04-06 07:08:47 UTC
hmm, ok... I'll ask the kernel guys what to do...

Comment 4 Brian "netdragon" Bober 2004-04-13 22:36:41 UTC
He said the kernel patch should fix the need for an automatic reload.

I've come to think that this should be handled at the kernel level.
I'm moving it to kernel, because I think that we should have a way to
make it so that the user has a chance to prepare the system for an eject.

By kernel option, when a program wants to eject removable media
without the user initiating the eject (i.e. if the user didn't use the
eject command directly -- if this can be known), then a blue screen
will come up giving the user a chance to prepare the computer for the
removable media to be ejected, and press ESC to cancel the eject.

The issue is that there are so many programs that do this without
thinking. It could damage sensitive drives on some computers with
front doors, etc.

Comment 5 Arjan van de Ven 2004-05-24 10:33:49 UTC
the kernel defaults to never ejecting. Ever.

Any other ejecting is initiated or enabled by userspace applications....

Comment 6 Arjan van de Ven 2004-05-24 10:38:15 UTC
... and you have to be root to do so basically even!...
(or at least have raw device access which is basically equivalent to root)

Comment 7 Harald Hoyer 2004-12-08 11:12:02 UTC
I will not fix this, cause it would affect to many existing burning tools, like
k3b, which rely on dvd+rw to behave exactly like it does.
Please convince the author.

Note You need to log in before you can comment on or make changes to this bug.