https://bugs.kde.org/show_bug.cgi?id=257602
--- Comment #29 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, i can reproduce the cdrskin problem by configuring libburn with option --enable-track-src-odirect The bug is a regression from end of 2009 by release 0.7.4, when cdrskin forgot that it must prepare special buffer memory by mmap(2) when libburn is configured to do O_DIRECT. Many thanks to King_DuckZ for reporting it. But i still need to know from where the cdrskin binary stems and, if it's not the standalone version, from where libburn.so (aka libburn4.so) stems. The proposed workaround really avoids the problem here: cdrskin -v dev=/dev/sr0 fs=32m -eject -waiti - <image.udf (Tested cowardly with a BD-RE medium. I still owe you a BD-R medium.) -------------------------------------------------------------------------- growisofs does not show the problem, because its memory preparations suffice. (Reading articles about O_DIRECT raises concerns about whether these preparations will always succeed.) xorriso does not show the problem because it uses the built-in fifo of libburn, which did not yet exist when cdrskin was founded in 2006. This fifo knows how to prepare its buffer for O_DIRECT. Nevertheless, the situation is tricky. libburn and its applications could by several ways get out of sync in this aspect. So now i am pondering whether to completely drop the opportunity in libburn to use O_DIRECT. Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
