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

[Andrei Borzenkov]

В Thu, 15 Jan 2015 11:36:33 +0100
Martin Pitt <martin.pitt at ubuntu.com> пишет:

> Andrei Borzenkov [2015-01-15 11:24 +0300]:
> > So what's the point of locking tray in the first place if it will be
> > unlocked as soon as you press eject button?
> 
> So that we can do a clean unmount and avoid the situation in the
> original post :-) Also, we can delay or fail the unlocking and
> ejection if the device is busy, e. g.  during burning. With the eject
> button directly working without telling userspace, we could never lock
> it during writing, nor do a clean unmounting.
> 
> > > 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?
> 
> Well, you deny someone with physical access the usage of a physical
> button.

Yes. This is the whole point of locking tray.

>         For any read-only mount I don't consider that friendly.

When you are performing installation and someone passing by ejects
installation media from your system? Sure, it is mush more friendly.
Tray is locked because it is in use. How can udev know mount point is
not being used right now?

> Locking is of course desirable (and ought to work) if the device is
> being written to.
>

Locking is desirable when you have long term work from CD and want to
make sure it is not interrupted. It does not matter whether this is
reading or writing.