mkisofs infinite loop (was: Re: problems with growisoft)

[Patrick Ohly <Patrick.Ohly@gmx.de>]

On Thu, 2004-11-04 at 15:21 +0100, Paolo Nason wrote: 
> Now I can reproduce the problem using that single file.
> Here is the name:
> $ls /tmp/nason/.nautilus/
> metafiles
> $ls /tmp/nason/.nautilus/metafiles/
> file:%2F%2F%2Fmnt%2Fcdrom%2Fbackup-2004-10-01-08%253A35%2Fusr%2Flocal%2Fhome%2Fnason%2Fc%252B%252B.xml
> 
> Now I do:
> growisofs -Z /dev/hdd -root backup1 -R -D \
> -graft-points /tmp/nason/.nautilus=/tmp/nason/.nautilus
> 
> which works, and then
> growisofs -M /dev/hdd -root backup2 -old-root backup1 -R -D \
>  -graft-points /tmp/nason/.nautilus=/tmp/nason/.nautilus

For various reasons I didn't look into this earlier. Sorry!

Anyway, let's see:

- the problem still occurs with mkisofs from cdrtools 2.01.01
- it has nothing to do with using -root or -old-root (not  really
  surprising, as -root is just a shortcut for more elaborate
  graft points and -old-root uses the same code as the normal
  multisession writing); these commands also cause mkisofs to
  lock up:
    mkisofs -R -o /tmp/first.iso nason/.nautilus
    mkisofs -R -o /tmp/second.iso -C 0,60000 -M /tmp/first.iso
nason/.nautilus
- -R is important to trigger the problem

A debugger shows that it gets stuck in multi.c/check_rr_dates():
it reads and parses the same extention block infinitely because
cont_extent (set by a CE entry in the original block) is not cleared.

A solution is to to clear those variables, just as it is done after
readsecs() in check_rr_relocation():

*** multi.c     Sat May 15 18:59:40 2004
--- multi.c.fixed       Sun Feb  6 17:42:18 2005
***************
*** 601,614 ****
--- 601,615 ----
                         * Continue to scan the extension record.
                         * Note that this has not been tested yet, but
it is
                         * definitely more correct that calling
parse_rr()
                         * as done in Eric's old code.
                         */
                        pnt = &sector[cont_offset];
                        len = cont_size;
+                       cont_extent = cont_offset = cont_size = 0;
                }
        }
  
        /*
         * If we have the same fundamental file type, then it is clearly
safe
         * to reuse the TRANS.TBL entry.
         */

Joerg, if you agree with this patch, can you apply it, please? I have
tested that the modified binary no longer runs into the infinite
loop and I have used it for an incremental backup which went
fine.

-- 
Bye, Patrick Ohly
--  
Patrick.Ohly@gmx.de
patrick@core.de (MakeCD related mails)
http://home.pages.de/~ohly/
http://makecd.core.de/ (MakeCD home page)