Bug 17744

Summary:	magicdev unlocks cdrom door when mounting it
Product:	[Retired] Red Hat Linux	Reporter:	Martijn <tinus>
Component:	magicdev	Assignee:	Elliot Lee <sopwith>
Status:	CLOSED RAWHIDE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6.2
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2001-02-19 17:58:11 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Martijn 2000-09-20 15:17:14 UTC

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
place.

Comment 1 Elliot Lee 2001-01-23 00:29:53 UTC

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
detection.

Comment 2 Martijn 2001-01-23 13:55:32 UTC

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 09:25:24 UTC

No reaction, so trying reopening.

Please consider my previous comment. If you disagree, please comment.

Comment 4 Elliot Lee 2001-02-19 17:43:33 UTC

File system corruption is hardly an issue with read-only media...
Remaining slothfully unconvinced.

Comment 5 Martijn 2001-02-19 17:58:06 UTC

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 23:27:22 UTC

It appears someone commented out the LOCKDOOR ioctl in CVS. Oh well.