Bug#688229: Burning data DVD looks successful but mounting fails

Thomas Schmitt scdbackup at gmx.net
Thu Oct 11 06:32:51 UTC 2012


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



More information about the pkg-gnome-maintainers mailing list