Am 29.07.21 um 17:53 schrieb Vincent Lefevre:
On 2021-07-29 17:05:23 +0200, Michael Biebl wrote:Am 29.07.21 um 16:33 schrieb Vincent Lefevre:On 2021-07-29 16:20:48 +0200, Michael Biebl wrote:And the comment from 2017 still holds true: https://lists.debian.org/debian-user/2017/04/msg00790.html" See the comment in there: # These rules will create symlinks for CD/DVD drives, to help old # programs which are unable to automatically discover the devices. # The first detected device gets the symlink, but this is not stable across # reboots. So, yes, what you see can happen depending on the order devices are discovered. " The kernel hasn't changed. It still probes devices asynchronously. There is not much we can do about that.The comment says: "The first detected device gets the symlink". If this were true, all symlinks would be the same (even though this would not be stable), which is not the case. BTW, aren't the devices numbered 0, 1, etc. in the order they are detected, so that one would expect always sr0 here?It appears you do not believe what I said. Feel free to propose a patch.This is not a question of belief, but of logic. Either sr0 or sr1 is the first detected device. Thus the 3 symlinks added by 80-debian-compat.rules are expected to be the same (possibly different from "sr0", which is hardcoded to "sr0" in 60-cdrom_id.rules).
This is a misunderstanding. Devices are detected asynchronously, which also means they can be processed in parallel (by independent udev worker processes). So it can very well be, that one udev worker processes the first line and the second udev worker skipping the first line due to the failing condition but processes the second line. There is no locking around those 3 lines which would mean they are always processed en bloc.
Anyway, I'll just drop those rules so this issue will be gone for good. Michael
OpenPGP_signature
Description: OpenPGP digital signature
