https://bugs.kde.org/show_bug.cgi?id=387765
--- Comment #13 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, the main riddle now is why the image is not copied to medium after the warning has been accepted and overridden by the user. @Leslie: I propose you create some dummy image file and make test with CDemu whether K3B accepts it for burning. The dummy could be e.g. a compressed tar archive. Maybe you can read and verify it from CDemu after the burn run looks successful. ------------------------------------------------------------------------- > "sudo mount -t udf -o loop file.iso /mnt/imagemiso" [...] worked after > I restart my computer. If the ones say that it is not an ISO 9660 but mount can mount it as UDF, then there remains only one explanation: It is an UDF without ISO 9660 superblock. Quite exotic and not deserving the name file.iso but rather file.udf. (I only have UDFs from mkisofs and Microsoft Inc. DVDs. They all have ISO 9660 superblocks.) What do you get from mount -o loop -t iso9660 file.iso /mnt/imagemiso ? If this refuses then we really have such an UDF. Userland programmers are surprised: I am trying to decipher the magic number definition of "file" for ISO and UDF at e.g. https://sources.debian.org/src/file/1:5.32-1/magic/Magdir/filesystems/?hl=1952#L1937 It looks like the UDF/ISO 9660 distinction by "NSR0" is done only after a "CDROM Filesystem" was detected by the signature of an ISO 9660 superblock. (The latter starts the former by >0 use cdrom See man 5 magic, pseudo-types "use" and "name".) K3B, too, seems to regard UDF as an extension to ISO 9660. > dd: invalid number: “” Something did not work with my proposal to determine the byte number 12 bytes before file end. Maybe you could compute it by hand and insert it into the command line dd bs=1 skip=$start count=12 if=file.iso | od -c Well, since mount -t udf works, my NRG theory loses its probability. Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.