[systemd-devel] cdrom_id and 60-cdrom_id.rules behavior

[Andrei Borzenkov]

On Thu, Jan 15, 2015 at 11:03 AM, Martin Pitt <martin.pitt at ubuntu.com> wrote:
> Hello all,
>
> Robert Milasan [2015-01-12  9:39 +0100]:
>> 1. add a CD/DVD into the driver
>> 2. mount the driver: mount /dev/sr0 /mnt/my_cd (ensure you don't
>> use the Gnome/KDE auto-mounting or reproduce this in a server setup)
>> 3. eject the media (using the hardware button) and add a new one media
>> (different disk)
>> 4. ls /mnt/my_cd (it will be an empty output or the previous media)
>>
>> Is this expected?
>
> no, it's not. It's been several years since I've actually had a CD
> drive and looked at this stuff, but this is how it is *supposed* to
> work today:
>
>  - Mounting (manually or through udisks) keeps the kernel default
>    policy of locking the door, so that users can't yank out a mounted
>    medium.
>
>  - *When* the tray is locked (the default), pressing the eject button is
>    supposed to cause a change event with DISK_EJECT_REQUEST.
>
>  - udev rules (60-cdrom_id.rules) picks that up and calls "eject
>    /dev/srX" on the device; the eject program takes care to unmount
>    everything before physical ejection.
>

So what's the point of locking tray in the first place if it will be
unlocked as soon as you press eject button?

>
> Right, because we didn't have the kernel (or userspace in udisks, as
> it was before that) polling for eject button presses. But users (IMHO
> rightfully) complained about the non-working button, and with the
> current system it's indeed so much more natural (if it works :) ).
>

You call it natural that now we apparently do not have any way to
actually lock CD tray?