Red Hat Bugzilla – Bug 206847
O_EXCL breaks mixed cd's
Last modified: 2013-03-05 22:47:02 EST
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 <email@example.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?
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?
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
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:
*** 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.
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.
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:
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:
you will be able to use a working cdda2wav that is even
better than cdparanoia.