Hi, > I am also going to print out the sector size. (Or just use GDB.)
The loop condition (read_bytes == sector_size) suggests that it must be 2048. Only this alignment is guaranteed for the output of libisofs. (Actually it would be a good reason for the 50 % bug if libisofs would not obey this alignment. But i am sure it does.) > BraseroBurn: (at burn-libburn-common.c:218) BraseroLibburn Premature > end of input encountered. Missing: 2048 bytes This is a message of libburn. Obviously the image size was pre-announced to libburn and it noticed a shortage when the input stream ended. Regrettably the number 2048 might not be an indication of the exact missing amount. It should be exact if libburn-1.2.4 is in use. Earlier versions always reported 2048. Fixed by http://libburnia-project.org/changeset/4762 Libburn version can be inquired by cdrskin -version libburn-1.2.4 should be installed as libburn.so.4.77.0 > $ dd if=/tmp/my_emulated_drive bs=2048 skip=16 count=1 | od -c > 0000000 377 330 377 340 \0 020 J F I F \0 001 001 001 \0 H This looks like the data start of a JPEG file. The data blocks of file content come after the trees. So this time the burn seems to have skipped even more blocks than with the original run. > $ dd if=/tmp/my_emulated_drive bs=30720 count=1 | od -c > 0040000 002 C D 0 0 1 001 \0 \0 \0 \0 \0 This is the Joliet Volume Descriptor. It should sit at block 17. So it looks like we lose 17 blocks at start. If the image does not contain only very few files, then we seem to lose further blocks inbetween. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
