Hi,
i think i can spot a byte eating problem in
http://git.gnome.org/browse/brasero/commit/?id=5ff86b48
resp. the master-branch commit
http://git.gnome.org/browse/brasero/commit/?id=1b8397ee252df2d554682ca2d694d5937fbf6e39
---------------------------------------------------------------------
@@ -200,6 +198,7 @@ brasero_libisofs_write_image_to_fd_thread
(BraseroLibisofs *self)
brasero_job_get_fd_out (BRASERO_JOB (self), &fd);
BRASERO_JOB_LOG (self, "Writing to pipe");
+ read_bytes = priv->libburn_src->read_xt (priv->libburn_src, buf,
sector_size);
while (priv->libburn_src->read_xt (priv->libburn_src, buf, sector_size) ==
sector_size) {
if (priv->cancel)
break;
---------------------------------------------------------------------
Variable read_bytes is set by a call of libisofs' resp. libburn's
burn_source.read_xt() which consumes data (one sector ?) into buf.
The call in the while() statement consumes another sector and thus
overwrites the previously read buffer without having done anything else
with that first buffer content.
Further down i see a similar change that looks more plausible
to me:
---------------------------------------------------------------------
@@ -254,7 +261,8 @@ brasero_libisofs_write_image_to_file_thread
(BraseroLibisofs *self)
priv = BRASERO_LIBISOFS_PRIVATE (self);
brasero_job_start_progress (BRASERO_JOB (self), FALSE);
- while (priv->libburn_src->read_xt (priv->libburn_src, buf, sector_size) ==
sector_size) {
+ read_bytes = priv->libburn_src->read_xt (priv->libburn_src, buf,
sector_size);
+ while (read_bytes == sector_size) {
if (priv->cancel)
break;
---------------------------------------------------------------------
It appears to me that this information is not yet known in
https://bugzilla.gnome.org/show_bug.cgi?id=630651
Feel free to add my technical opinion to that bug report.
I will try to contact Philippe Rouquier directly on this issue.
Swallowing the first sector is enough to make the image not mountable.
But regrettably a single lost sector does not yet explain the fact
that we find Joliet data at block 16.
The normal layout of an ISO 9660 image with Joliet (and no
El Torito boot equipment) would be
Block 16: ISO (660/ECMA-119 Primary Volume Descriptor
Block 17: Joliet Volume Descriptor (which would not contain
names of payload files like IMG_2428.JPG)
Block 18: Volume Descriptor Set Terminator
libisofs will then pad up to 64 KB and first write the
ISO 9660 + Rock Ridge tree. Several blocks to be expected.
Only then comes the Joliet directory tree with those entries
which we found at block 16.
So we look for a byte eater that swallows at least a few dozen
sectors and not only the first one.
Nevertheless, the code pieces, where above change was made,
look much like the place where the emerging damage of an
ISO 9660 image can be watched ... if it is not caused there.
A very good starting point for debugging, i'd say.
Telling from the function names, i would say the change which
i deem bad is in charge for writing to optical media, whereas
the good one is in charge for writing image to a file in hard
disk.
An according difference in success can be found in several
Brasero bug reports of the last years.
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
