OSDev.org

well, i dont know..... but why is it so that the linux cdrom driver locks the door after mounting, while windows doesn't? any historic reasons?

I'd assume it's so that the mounted drive doesn't disappear mid-transfer or somesuch. I personally prefer it non-locked though, that way if something dies I can always claim my disc back and possibly error it into working again (sounds strange, but some of my occasional CD related issues have been easily fixed by ejecting the drive so that locking up trying to read it turns into giving up and telling me the disc is gone)

Linux isn't very smart when it comes to removable devices. Try writing something to floppy: Windows knows it's a removable device, and does the actual writing at the earliest time possible. Linux thinks to itself, "hey, I can buffer that", and does the actual writing only at the time you unmount the drive.

If I were as brain-dead as that, yes, I would lock the drive tray, too.

(Sorry. Just been struggling with Ubuntu and feeling like flaming Linux once again. )

Solar wrote: Linux isn't very smart when it comes to removable devices. Try writing something to floppy: Windows knows it's a removable device, and does the actual writing at the earliest time possible. Linux thinks to itself, "hey, I can buffer that", and does the actual writing only at the time you unmount the drive.

I prefer that behaviour personally, writing to floppies is extremely slow, having the ability to add and remove files from the drive before finally commiting only when I'm reasonably sure I'm done seems to make much more sense. (Writing directly to the disk will most likely mean that there will be large amounts of seeking to and from the FAT/Inodes for every file, doing the copy in bulk should be faster overall)

If you don't like the drive locking behaviour then open /usr/src/linux/drivers/ide/ide-cd.c, go to line 2057 [kernel 2.6.16] and comment out all of the function body for "cdrom_lockdoor" and replace it with: [Untested, this should work fine though since the driver supports drives with doors that can't be locked - and this is what already happens in that event].

If I'm building a floppy for something, I personally work with a loopback mounted floppy image instead, and just use dd to finally write it.

Alternatively, if I simply need to throw a single file into a floppy, I use mtools.

As such I rarely, if ever, actually mount real floppies.

As for CDs, I like the locked mount too. It saves me from accidentally opening the drive (yes I've done it several times, don't ask) and since I generally use eject (or some graphical alternative) to umount+eject CDs anyway, I don't care if the button to press happens to be virtual..

How about going a slightly Windows route with an option for it? "Write data to media as soon as possible (may prevent data loss due to power outages or accidental ejection)" or "Buffer data before writing (may provide a performance boost)", let the user decide between performance and reliability.

especially when you insert a scratched disk and mount it, and try to read that specific file, the driver keeps on trying, doesn't give up easily [huge timeout value], so neither can i operate the system (yes... many times the processor usage shoots up) normally, nor can i say "shut up. i know the disk is bad. just poking if, by any chance, you could read it", like in windows.

i think it will be good if we have some command line tool to unlock the tray..... (while the disk is still mounted.... atleast if it is a CD-R???)

I remember it being relatively easy to disable that locking by hacking the source. I remember it not causing too much trouble either (not more than taking a floppy out, anyway). I would assume there is probably at least 10 patches for doing that. Google around.

I MIGHT remember wrong though, and I'm too lazy to check now, unless your willing to pay me.

nah...

we are in the free software world mr...

n i wont pay anyone for that...

prashant: your signature (Time = Money.) says it pretty well.

While I like free software, and sometimes contribute or release something myself, I don't think people should assume that free software implies that people's time is free.

I'd be all for the model where software is free, but if you want someone to change/fix/extend it, then you're supposed to pay for the time used. Too bad it only seems to work on enterprise level where the cost of software is insignificant anyway, once you look at support costs.

Just curious:

From the hardware point of view, is there really no way to get notified when the user presses the 'eject' button on the drive, even when the tray is locked?

Technically (at least with older drivers, don't know about new onces) there isn't even a way to know when user has inserted a disk into the drive.

So even the automount/autorun functionality really relies on polling the drive every 5 seconds or so.

Somebody please correct me if I'm wrong.

i've noticed that the moment the disc starts spinning, the mouse cursor changes(indicating that the event has been recognized). and that works for my CDROM drive, which is like 8-9 years old ;D.. or maybe the checking frequency Mystran said about is quite high, maybe per second?

I remember Win95 using something like once every 5 seconds. If you think about it, it's enough, because nobody's going to get a drive open, a CD into the drive, and the drive closed in less than 5 seconds. Considering how long it takes to put the disk in, having to wait an average of 2.5 seconds for the OS to detect that a disk is inserted is ... well ... not very noticeable.

i think it will be good if we have some command line tool to unlock the tray..... (while the disk is still mounted.... atleast if it is a CD-R???)

I hope you were being sarcastic, and that all of you know about the ?eject? command(with slackware at least) or is this not what you meant?
Windows XP does that buffer thing, when you put a file in the CD folder, windows just moves the file to a folder representing the CD and you click a button to write.