Red Hat Bugzilla – Bug 206847
O_EXCL breaks mixed cd's
Last modified: 2017-04-11 10:03:33 EDT
Description of problem: If the data track is mounted cdparanoia will fail because it wants O_EXCL. Looking at the change log this was added * Tue May 06 2003 Peter Jones <pjones@redhat.com> alpha9.8-16 - fix warnings on switches - use O_EXCL which is a long time ago. Running without this patch works fine for me, come to think of it, I can't imagine when yould would need O_EXCL but I suppose it was added for a reason. Can we remove it please? Thanks, David
Alan Cox: Nowadays, is it safe to let cdparanoia directory access the CD drive to extract the audio tracks _while_ the data part of the mixed CD is mounted? Thanks, David
Comment 1: s/directory/directly/
The audio apps are doing this nowdays and seem ok. There should be no problems unless you issue very long commands that hog the bus (like the CD fixate). I don't think cdparanoia will trigger any of those while reading. The actual driver layer (both scsi and ide) is happy to have mixed raw and fs commands outstanding except for that limitation, and it's a tested path because of the SMART utils.
It's more problematic than just removing it. pjones and I talked about this a few weeks back. The crux of the problem is that if you're burning a CD and then e.g. insert your iPod, then some Music Player program (e.g. Rhythmbox, Banshee) may be launched. And said player may do silly things like check the optical drive for audio cd's. And if it doesn't use O_EXCL it might interfere with the burning process. I think the conclusion is that O_EXCL is in general inadequate and we need some better, kernel-enforced, way of locking. What that looks like is pretty difficult to say. (Adding dcbw to Cc list as he just ran into this issue with his Scandinavian heavy rock mixed CD's.)
Peter, perhaps you can chip in with the problems you saw re removing O_EXCL? And potentially some thinking about a more adequate form of locking if this is required. Thanks.
The kernel doesn't have enough information currently to do any of this because the cdrecorder is using the same interface as many other apps and they have different policies with different requirements. At the very least you'd need to modify all the CD burner apps to provide more info or enforce that O_EXCL blocks all other non O_EXCL openers after that point ?
NB: This O_EXCL setting breaks all attempts to rip CDs under KDE, because inserting a CD starts a "kio_audiocd" process that prevents cdparanoia from accessing the disc. It's really annoying to have to keep typing "killall kio_audiocd" every time I insert a new CD. See bug 411701 and http://bugs.kde.org/show_bug.cgi?id=135669 for more details.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
*** Bug 411701 has been marked as a duplicate of this bug. ***
Mary Ellen - I closed your other bug dup to this since it really is. Peter - Any chance of some action on this in the near future? I'm not sure what the right course is reading this bug and the other one, it's a thorny problem (but a long standing one)
For the API question this is an upstream discussion to be had between desktop people and the block layer folks. Not a Red Hat internal one
cdparanoia is based on a 1997 version of cdda2wav and does not issue SCSI commands AFAIK because the code was never upgraded to a recent cdda2wav. On the other side, cdda2wav included SCSI generic support in 2001, it thus is able to give much better results than cdparanoia does. In spring 2005, the paranoia code from Monty was taken and made portable by the cdrtools project. Recent cdrtools include a cdda2wav with paranoia support that gives you better results than cdparanoia. Note that cdda2wav does not open the devices using O_EXCL and thus does not suffer from the problem. ftp://ftp.berlios.de/pub/cdrecord/alpha/
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
Declaring Fedora 9 EOL does definitely not fix the problem. The problem is caused by a design bug in hald and by the fact that some applications make the mistake to follow this design bug. If you use the original cdrtools from: ftp://ftp.berlios.de/pub/cdrecord/alpha/ you will be able to use a working cdda2wav that is even better than cdparanoia.