bugCompact Disc Input and Control Library - Bugs: bug #39354, Bug in iso-read for ISO9660 images...


bug #39354: Bug in iso-read for ISO9660 images in 0.90 but not in 0.81

Submitted by:  Leo Baschy <infrastrug>
Submitted on:  Fri 28 Jun 2013 02:35:52 AM UTC  
Category:  run-time error Severity:  5 - Average
Item Group:  libiso9660 Status:  None
Privacy:  Public Assigned to:  Rocky Bernstein <rocky>
Open/Closed:  Closed

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Mon 02 Sep 2013 06:58:46 AM UTC, comment #15:

Am confirming this bug tests as fixed in c8d044e (as well as cb14b08) in 32 bit Enterprise Linux 6.4. Thank you for guidance at first and for integration of fix and test.

Leo Baschy <infrastrug>
Sun 01 Sep 2013 11:56:18 PM UTC, comment #14:

Let me retract my last comment. This change DOES work for me.

The change was made in git commit c8d044e.

What remains is adapt iso-read-test.sh so it can be included in the normal tests.

Rocky Bernstein <rocky>
Project AdministratorIn charge of this item.
Sun 01 Sep 2013 11:18:26 PM UTC, comment #13:

Thanks, Mike. I've changed the default but that doesn't address this bug for me. Did it for you? Or you Leo?

Rocky Bernstein <rocky>
Project AdministratorIn charge of this item.
Wed 28 Aug 2013 08:40:39 PM UTC, comment #12:

change the 4th arg to AC_ARG_ENABLE(rock) to "yes". the code atm sets rock to disabled by default, but the intention is to enable it by default.

- enable_rock=$enableval, enable_rock=no)
+ enable_rock=$enableval, enable_rock=yes)

Mike Frysinger <vapier>
Tue 20 Aug 2013 12:43:05 AM UTC, comment #11:

Compare iso-info output with iso-info --no-rock-ridge output.

And heck config.h to see HAVE_ROCK is #defined (to 1).

Rocky Bernstein <rocky>
Project AdministratorIn charge of this item.
Mon 19 Aug 2013 08:31:56 PM UTC, comment #10:

Is there a simple (command line) way to tell whether the specific version of iso-read (or libcdio) one is looking at has been compiled with or without Rock Ridge support?

An answer might help find the cause faster.

Leo Baschy <infrastrug>
Mon 19 Aug 2013 03:33:19 AM UTC, comment #9:

Thanks for the pinpointing this.

It looks like things go awry with Patch #7129 from Mike Frysinger: https://savannah.gnu.org/patch/?7129

The most obvious change is to try to properly handle ISO9660 without Rock-Ridge extensions and possibly those with Rock-Ridge extensions got messed up.

I spent a little time trying to pinpoint which part of the patch has problems to no avail. I don't have much free time to spend on this, so to the extent others can pitch in that would be appreciated.

Rocky Bernstein <rocky>
Project AdministratorIn charge of this item.
Wed 14 Aug 2013 01:08:36 AM UTC, comment #8:

Without detailed description of the lengthy process and repeated attempts, here is what seems to be a reproducible result of bisection:


because the earlier of these two commit doesn't build.

Test done on 32-bit Enterprise Linux 6.4.

In addition to script from 39373 also used the following bisect-helper.sh made for this purpose:

Tried various ranges from 0.81 to HEAD.

Leo Baschy <infrastrug>
Fri 09 Aug 2013 03:29:56 PM UTC, comment #7:

Thanks for the info.

Now what is needed is to use that in a git bisect to find a commit which caused this to fail.

Rocky Bernstein <rocky>
Project AdministratorIn charge of this item.
Fri 09 Aug 2013 03:16:25 PM UTC, comment #6:

For fixing this regression bug 39354 if you use the test script from 39373 for now (before 39373 is fixed) you should only look at the 3G size .iso file results (less than 4G size where bug 39373 kicks in).

Leo Baschy <infrastrug>
Tue 30 Jul 2013 01:30:43 PM UTC, comment #5:

Thank you for creating this test. There's one more thing that with this test that will greatly speed up fixing this bug.

If you use that test in "git bisect run" (see http://git-scm.com/book/en/Git-Tools-Debugging-with-Git#Binary-Search ) to narrow the problem down to a commit, I'll make sure this gets fixed faster because I can probably enlist the help and advice of those who made the change. Thanks

Rocky Bernstein <rocky>
Project AdministratorIn charge of this item.
Mon 29 Jul 2013 07:49:40 PM UTC, comment #4:

Now there is a test script at bug 39373.

Leo Baschy <infrastrug>
Sun 30 Jun 2013 02:20:56 AM UTC, comment #3:

Maybe I wasn't clear enough in comment #1, yes I've verified the defect in Scientific Linux 6.4 (as a host too, not just as sample .iso file).

That means same should be in RHEL 6.4 and CentOS 6.4. They come with 0.81 and it works. Then I built 0.90 from sources and installed it and the defect showed. Then I built 0.81 from sources this time, no defect again. Reproducibly 0.90 is broken versus 0.81 works.

So if you have a RHEL 6.x or derivative, grab the .iso I've linked and see defect with 2/3rd of 3000+ files e.g.

and interestingly no defect with 1/3 of 3000+ files e.g.

Leo Baschy <infrastrug>
Sat 29 Jun 2013 05:29:49 PM UTC, comment #2:

I don't have a Mac or access to OSX. Does this fail on an OS other than OSX?

Rocky Bernstein <rocky>
Project AdministratorIn charge of this item.
Fri 28 Jun 2013 07:30:31 PM UTC, comment #1:

Took 0.90 sources and built and installed in Enterprise Linux 6.4 and it also fails for same file Packages/ConsoleKit-libs-0.4.1-3.el6.i686.rpm from that same .iso file.

It did work minutes earlier on that machine with 0.81.

This looks like a regression, any platform. Not Mac specific.

There was a typo in original post, but to be clear, it is the ConsoleKit-libs file that cannot be read from that .iso file (and 2/3rd of the files on that .iso file cannot be read).

And it does work for the remaining 1/3rd of the files on that .iso file, and in 0.81 it used to work for all of them.

That .iso file is a free download of a Linux distro, linked in original post, so you can try it out.

Leo Baschy <infrastrug>
Fri 28 Jun 2013 02:35:52 AM UTC, original submission:

Using ISO file SL-64-i386-2013-03-18-Install-DVD.iso with NrvrCommander, which for some feature uses iso-read.

Works fine with iso-read version 0.81 x86_64-koji-linux-gnu coming with RHEL 6.3 and 6.4.

Fails with iso-read version 0.90 x86_64-apple-darwin12.2.0 from MacPorts in OS X 10.8.

Version 0.90 build on Mac fails (but 0.81 in Linux succeeds) on 2221 of 3104 files in that .iso. For example it fails at

Fails with error

For example, however, it succeeds in same .iso at

Version 0.81 in RHEL flavor Linux succeeds on all files in that .iso file.

Leo Baschy <infrastrug>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #28838:  bisect-helper.sh added by infrastrug (864B - application/octet-stream - bisect-helper.sh script use with iso-read-test.sh, worked at least 0.81 to 0.90)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by vapier (Posted a comment)
  • -email is unavailable- added by rocky (Posted a comment)
  • -email is unavailable- added by infrastrug (Submitted the item)
  • -email is unavailable- added by infrastrug

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-09-02 rocky Open/ClosedOpen => Closed
    2013-08-19 rocky Assigned toNone => rocky
    2013-08-14 infrastrug Attached File- => Added bisect-helper.sh, #28838
    2013-08-07 rocky SummaryBug in handling ISO9660 images over 4G in 0.90 but not 0.81 => Bug in iso-read for ISO9660 images in 0.90 but not in 0.81
    2013-07-30 rocky Item Groupiso-read => libiso9660
        Summaryiso-read 0.90 on Mac fails for many but not for all files in .iso => Bug in handling ISO9660 images over 4G in 0.90 but not 0.81
    2013-06-28 infrastrug Carbon-Copy- => Added infrastrug

    Back to the top

    Powered by Savane 3.3