Bug 17744 - magicdev unlocks cdrom door when mounting it
magicdev unlocks cdrom door when mounting it
Product: Red Hat Linux
Classification: Retired
Component: magicdev (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Elliot Lee
Depends On:
  Show dependency treegraph
Reported: 2000-09-20 11:17 EDT by Martijn
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-02-19 12:58:11 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Martijn 2000-09-20 11:17:14 EDT
When mounting a cdrom, magicdev calls ioctls that control the behaviour of
a cdrom player. It sets some things that were 'just copied from autorun'
and it tries to lock the drives door.

With my cdrom player, the things that were just copied unlock the door.

Magicdev does not have any reason to go around mucking with my cdrom drive
settings, so it shouldn't touch them. That way I can change them to my
likings, not the author of magicdev's likings. If we were all to have the
same settings, there wouldn't have been a point of having them in the first
Comment 1 Elliot Lee 2001-01-22 19:29:53 EST
Not convinced of correctness or lack thereof, and the autorun authors do it, so
I will stick with existing convention because it may be necessary to do
Comment 2 Martijn 2001-01-23 08:55:32 EST
The only thing that could possibly have anything to do with detection is the
CDO_AUTO_CLOSE setting. If you set this, the cdrom tray will be closed whenever
a process opens the cdrom device. Because magicdev uses a polling approach to
look if there is a cdrom in the drive, it'll try to open the device every x
seconds and the cdrom drive will unintentionally close while the user is
inserting a cdrom.

The CDO_CHECK_TYPE may look like detection, but it will only tell a process that
tries to open the cdrom device for reading data that opening it failed if there
is an audio cd in the drive instead of giving heaps of kernel error messages.

From the documentation (/usr/src/linux/Documentation/cdrom/cdrom-standard.tex):

'The door is locked to prevent file system corruption.'

In reality, the door is not locked because the CDO_LOCK flag is unset by magicdev.

Also if you look at the (new?) autorun source, 
( http://parzelle.de/Linux/Applications/#autorun )
you will see that this behaviour has been fixed.

Please consider reopening this bug.
Comment 3 Martijn 2001-02-19 04:25:24 EST
No reaction, so trying reopening.

Please consider my previous comment. If you disagree, please comment.
Comment 4 Elliot Lee 2001-02-19 12:43:33 EST
File system corruption is hardly an issue with read-only media...
Remaining slothfully unconvinced.
Comment 5 Martijn 2001-02-19 12:58:06 EST
The file system is not really corrupted of course (at least the file system on
the CD). However, because the data about the filesystem in memory is supposed to
reflect the contents of the CD, but does not match what's on the CD, the kernel
becomes totally confused, making it impossible to unmount the cdrom and causing
a lot of log messages.

Try it for yourself if you do not believe it.

However, the question whether corruption occurs is beside the point. It is a bug
anyway, because the program is invisibly changing settings where it has no
business changing them. Why else would the autorun authors have changed it?
Comment 6 Elliot Lee 2001-03-15 18:27:22 EST
It appears someone commented out the LOCKDOOR ioctl in CVS. Oh well.

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