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

Paul Menzel pm.debian at googlemail.com
Thu Oct 11 12:44:53 UTC 2012


Dear Thomas,


Am Donnerstag, den 11.10.2012, 13:19 +0200 schrieb Paul Menzel:

> Am Donnerstag, den 11.10.2012, 11:40 +0200 schrieb Thomas Schmitt:
> 
> > staring at lines 201, 202, and 216 of
> >   http://git.gnome.org/browse/brasero/tree/plugins/libburnia/burn-libisofs.c
> > 
> > i realize that this loop drops every second block !
> > 
> > ----------------------------------------------------------------
> >   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) {
> > 
> >      ... process block that was read by while() statement ...
> > 
> >      read_bytes = priv->libburn_src->read_xt (priv->libburn_src, buf, sector_size);
> >   }
> > ----------------------------------------------------------------
> > 
> > This would well explain why block 17 ends up at block 8.
> > 
> > 
> > It is tempting to also claim victory over the 50 % bug, but i
> > cannot yet make up a plausible explanation. With the 50% bug
> >   https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/780117
> > it is libisofs which reports 50 % progress, when loop or libburn
> > close the shop.
> > 
> > The many CD complaints in this Ubuntu bug could well be caused
> > by above killer loop, though.
> 
> As already spoilered in my reply to #690207 [1], with the libburn output
> patch attached it confirms that half of the bytes are missing.
> 
>         BraseroBurn: (at burn-libburn-common.c:218) BraseroLibburn Premature end of input encountered. Missing: 48709632 bytes
> 
> These are around 47 MB and indeed comparing the sizes yields the
> following.
> 
>         $ du -sh folder
>         94M	/home/joey/folder
>         $ du -sh /tmp/my_emulated_drive 
>         47M	/tmp/my_emulated_drive
> 
> So all the bugs seem to be the same and Brasero just displays the error
> differently or it is not noticeable with smaller amounts that the
> progress bar stopped earlier.
> 
> I will try to cook up a patch for fixing the loop now.

It looks like it is as simple as the following.

diff --git a/plugins/libburnia/burn-libisofs.c b/plugins/libburnia/burn-libisofs.c
index 3c25224..3919281 100644
--- a/plugins/libburnia/burn-libisofs.c
+++ b/plugins/libburnia/burn-libisofs.c
@@ -199,7 +199,7 @@ brasero_libisofs_write_image_to_fd_thread (BraseroLibisofs *self)
 
        BRASERO_JOB_LOG (self, "Writing to pipe with sector size %i bytes", sector_size);
        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) {
+       while (read_bytes == sector_size) {
                if (priv->cancel)
                        break;

I am building it right now.


Thanks,

Paul


> [1] http://bugs.debian.org/690207
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20121011/d03ba896/attachment.pgp>


More information about the pkg-gnome-maintainers mailing list