[systemd-devel] cdrom_id and 60-cdrom_id.rules behavior
arvidjaar at gmail.com
Thu Jan 15 00:24:01 PST 2015
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
> - *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?
More information about the systemd-devel