After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 550353 - gvfsd-cdd prevents cd drive from opening
gvfsd-cdd prevents cd drive from opening
Status: RESOLVED NOTGNOME
Product: gvfs
Classification: Core
Component: general
0.2.x
Other All
: Normal normal
: ---
Assigned To: gvfs-maint
gvfs-maint
Depends on:
Blocks:
 
 
Reported: 2008-09-02 02:33 UTC by Holger Koch
Modified: 2008-09-04 18:11 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22



Description Holger Koch 2008-09-02 02:33:41 UTC
Please describe the problem:
Since Ubuntu Hardy when ripping CDs with Grip the application is unable to eject the CD automatically after ripping. It is possible to trigger the drive to open manually but only for a short moment, after one second the drive closes again, then it is not possible to open the drive unless grip is closed. sudo lsof /dev/scd0 revealed that the process gvfsd-cdd is connected to the CD drive. Killing this process enables the application to auto-eject the CD again. But each time a new CD is mounted the process starts again.

Steps to reproduce:
1. Insert a CD, start Grip and rip the CD
2. Grip refuses to open the CD tray automatically
3. Open the tray manually


Actual results:
The tray opens only for one second, then closes again and can only be opened after I have closed the application.

Expected results:
Normally Grip should eject the CD automatically after ripping (according to the application's settings)

Does this happen every time?
in about 95% of all cases

Other information:
I first reported this bug on launchpad. see this bugreport for more info:
https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/241579
Sebastien Bacher suggested I should report to you.
Thankx.
Comment 1 David Zeuthen (not reading bugmail) 2008-09-04 18:11:41 UTC
The problem is mostly likely that the application is opening the device with O_EXCL most likely through the cdparanoia library (perhaps indirectly through gstreamer). 

Since gvfs-cdda already has opened the drive (not using O_EXCL unless the libcdio library isn't patched) this means the application fails.

So this is not a bug in gvfs-cdda; it's a bug in the application (or one of the libraries that it's using).