> This would change the behavior. Do you plan to alternatively allow to > have the eject button blocked as before? Note that people may likke to have > the > button locked in order to prevent to eject the media by accident.
We provide an SMF property for rmvolmgr for this. There is no similar GConf property for the GNOME volume manager as far as I know, but it should be easy to send a patch upstream to add this. > BTW: cdrecord (when going to write to a CD / DVD / BD) loads the medium, > then locks the eject button and will not unlock the eject button before > the write process to the medium has been completed. Is there a potential > problem that could remove the lock from the eject button that has been > established by cdrecord and thus make cdrecord less reliable than before? The effect would be the same as issuing eject(1) command during cdrecord. The latest version of HAL provides interface locking: http://people.freedesktop.org/~david/hal-spec/hal-spec.html#locking Applications like cdrecord can grab the lock for the duration of the critical operation, which would prevent any DBus method from being called on the locked interface, including Eject() method. HAL in Solaris, however, needs to be upgraded to the latest version to get this functionality. -Artem
