I've just tried to track down the problem and find specific rules interfering with CD burning process. As of the rules reacting on /dev/sr0 change, there are at least two independent problem sources: /sbin/blkid (called by udev) and devkit-part-disk-id from devicekit-disks.
When either of them is called, it's enough to prevent CD burning. Therefore, if scsi-to-block event forwarding is the right thing, we have at least two bugs, one in udev and another in devicekit-disks (or maybe we need a locking API for udev, and CD-burning software should use it to prevent intrusive udev event handlers from firing during the burning process). The call to scsi_id, by itself, seems to be harmless. -- Regards, Anton Kovalenko +7(916)345-34-02 | Elektrostal' MO, Russia -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
