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

[Oliver Neukum]

On Mon, 2015-01-12 at 04:15 -0800, Greg KH wrote:
> On Mon, Jan 12, 2015 at 09:39:30AM +0100, Robert Milasan wrote:
> > Hello, a while back, around 2011, in cdrom_id was added --eject-media,
> > --lock-media and --unlock-media for not much explanation.
> > 
> > Now, recently some people noticed that this might actually be a
> > problem. 
> > 
> > Reference: http://bugzilla.opensuse.org/show_bug.cgi?id=909418
> > 
> > Here is a scenario:
> > 
> > 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?
> 
> Yes, because you didn't unmount the media and tell the kernel that the
> filesystem is now gone.

You are correct, but not really helpful :)
Let me rephrase. Is this desirable?

It doesn't tell us whether the hardware button should eject the medium
in the first place.

> > Also, I remember a while back (long time ago) that
> > once you added a media into the driver and it was properly mounted, you
> > couldn't eject the media until you unmounted the media.
> 
> It depends on the hardware, some devices support this, others don't.

If the device does not support locking the door, the question is moot.
We need to be able to handle surprise removal. That doesn't mean we
should in effect never lock the door if we can do so.

> > NOTE: This works somewhat OK in the desktop setup, probably due to
> > udisks (using Gnome/KDE), but in the console not really.
> 
> Then use udisks :)

To do what? The kernel on its own and udev on their own behave
differently. What is the correct way?

	Regards
		Oliver