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.
