Bug Description

Binary package hint: udisks

Steps to reproduce:
1. log in to Gnome desktop
2. Insert CD or DVD in drive and wait for icon to appear on desktop
3. Press the physical eject button on the DVD/CD drive(do NOT click the software eject by right clicking the icon)

Expected results:
CD or DVD is ejected and desktop (and places menu) Icon disappear for the CD or DVD

Actual results:
CD or DVD is ejected and the desktop icon remains on the desktop (The DVD or CD remains in the 'Places' menu as well)

When I inserted a CD, this call to open() succeeded and returned a valid fd. I
enabled POLL_SHOW_DEBUG, and according to the debug message, the device was
polled every 2 seconds as expected.

However, after the device is mounted, either by udisks --mount or by calling
sudo mount myself, open(device_file) always returns -1 here.
Then, I press the physical eject button on my CDROM to get its tray opened. The
polling code should let udisks detect the media removal and then invokes
ForceUnmount, but this is not the case. The call to open() kept returning -1
every 2 seconds and udisks didn't detect the media change at all. Checking
errno, "Device is busy" is reported.

Then I remove the O_EXCL flag and perform the whole test again. This time,
after the CD is removed by pressing physical eject button, the open() call
succeeded and returned a valid fd. Then, udisks detects the media change and
gracefully perform ForceUnmount for it. Everything works fine as expected.

In addition, when "Device is busy", I tried fuser and lsof, but none of them
demonstrates other process using the device. However, if I unmount the device
either by calling sudo umount or udisks --unmount, this error is gone and
open() can return a valid fd. Then everything works.

Removing O_EXCL from this open() call seems to fix the issue, but this of
course is not the correct way to fix it.

Another interesting thing I found is, if I call udisks --poll-for-media change
manually after forced removal of CD with physical eject ...

No, these two patches handles totally different problems.
The patch you mentitioned focused on supporting the legacy IDE driver via ioctl() while my patch fixed the O_EXECL part which is not done in previous patches. In previous patch, there is a line which reads // TODO: check if media is mounted.
Basically my patch does this TODO stuff, checking if media is mounted.
Please review it again if possible. Thanks.

Why upstream udisks authors refuse integrating theses important patches?
Without them, udisks never works with some devices.
When you open a decice with O_EXECL and it's mounted, you'll get EBUSY error.
So when we get EBUSY, we check if it's mounted. If it is, we open it without O_EXECL.
Otherwise, that means other programs, such as cd burner, are using the device and we shouldn't touch it.
That's basically why is_mounted() is called here.

Personally, I think the correct way to integrate these two patches is like this:

} else if (errno == EBUSY) { // no need to check for ide_cd here
+ /* From hal/hald/linux/addons/addon-storage.c: */
+ /* this means the disc is mounted or some other app,
+ * like a cd burner, has already opened O_EXCL */
+
+ /* HOWEVER, when starting hald, a disc may be
+ * mounted; so check /etc/mtab to see if it
+ * actually is mounted. If it is we retry to open
+ * without O_EXCL
+ */
+ if (is_mounted (device->dev_path))
+ {
+ fd = open (device->dev_path, O_RDONLY | O_NONBLOCK);
+ } if (fd != -1 && device->is_ide_cdrom) { // only IDE cd needs this. poller_check_ide_cdrom (fd, device); close (fd); }
}

If someone knows the upstream udisks authors, talk to them please.
It's really bad that these important patches cannot be accepted since without them udisks never works correctly.
The upstream authors tend to think that people has the latest hardware + the most updated kernel.
This is just wrong in the real world.

@Jani: The actual polling support is easy to add, I already have a patch for it. It just needs some more changes to also properly handle the eject button; I discussed the approach with the other upstreams, we found an agreement, and I'm working on it now.

My kernel-polling patches are still being reviewed upstream, and they look good so far. But I think at this point they are too intrusive and have missed the Natty line, so I'll fix PCMan's patch to actually build (which looks simple), and upload that as a workaround for natty.