On 15/11/2025 16:20, Thomas Schmitt wrote:
openat(AT_FDCWD, 0x7fff73a82300, O_RDWR|O_EXCL|O_NONBLOCK) = -1 ENOENT (No such file or directory) ... repeats 26 times ... uname(0x7fff73a82170) = 0 openat(AT_FDCWD, 0x7fff73a82300, O_RDWR|O_EXCL|O_NONBLOCK) = -1 ENOENT (No such file or directory) ... repeats 255 times ...[...] Does anybody have an idea how to find out which file paths hide behind the hex numbers 0x7f102f5f6480 and 0x7fff73a82300 ?
Not being familiar with strace internals, I suspect that you may need to patch the tool to add a special case for openat. Other alternatives are debugger or auditd.
From my point of view, the main question is whether developers/maintainers of wodim are active.
From links posted to the previous thread on this tool, my impression is that wodim may fail trying to lock large enough chunk of RAM (that requires specific capabilities).
I am not familiar with issues related to license of original cdrecord.I have seen rant of the cdrecord author on permission model for SCSI commands used in Linux kernel. Perhaps very specific usage of ioctl's is assumed and some limitations still may be obstacles. Thomas, certainly you should be closely familiar with these issues.
04711 mode for the binary looks like excessively drastic measure.