Is this still a problem?

By now NrvrCommander not only has a workaround, but also a nice demo of this defect.  That means both we can live with it, but also there is an easy way to see its impact.

Here is how to see it:

git clone https://github.com/srguiwiz/nrvr-commander.git
sudo nrvr-commander/installlocally.py
nrvr-commander/dev/nrvr/diskimage/isoimageexperiment.py --help
nrvr-commander/dev/nrvr/diskimage/isoimageexperiment.py -j \
  ~/Downloads/ubuntu-12.04.3-alternate-i386.iso

This specific run assumes you have downloaded ubuntu-12.04.3-alternate-i386.iso from Ubuntu alternative downloads.

There are different results whether libcdio is 0.81 (in RHEL 6.x) or git HEAD as of today, early October 2013.

Everything is good with 0.81.

Current git HEAD (and 0.90 presumably) though after other lines end with

Exception: too many (37 of 1938) failures reading ~/Downloads/ubuntu-12.04.3-alternate-i386.iso

With wrong information from iso-info then iso-read wasn't able to succeed.

This script would work with other .iso files as well, for testing purposes.  It is open source, and it has a --help option.

For this defect, for Linux distro .iso files, NrvrCommander has a workaround, which is on by default now.

We don't know yet how it will work when we work with Windows .iso files.

But clearly, this is a regression.

Despite its oddity, this problem has been encountered in serious engineering use.

I have tried to make a simpler test case, like for bugs 39354 and 39373, but no luck yet, so here described with a file we did have a problem with.

When reading from publicly available (about 700MB) .iso file

ubuntu-12.04.3-alternate-i386.iso

then iso-info -f (or -l) should output a line with

firewire-core-modules-3.8.0-29-generic-di_3.8.0-29.42~precise1_i386.udeb

while in fact it outputs incorrectly

firewire-core-modules-3.8.0-29-generic-di_3.8.0-29.42~precise.ude

Bisection has indicated

1f1c20771e555782b66cdab7b72983ff85950b26 is the first bad commit
commit 1f1c20771e555782b66cdab7b72983ff85950b26
Author: Pete Batard <pbatard@gmail.com>
Date:   Mon Mar 5 17:06:01 2012 +0000

    Joliet improvements

    * support discs with more than one secondary volume descriptors
    * add Joliet support for extract sample
    * add fallback to non-Joliet if non-Joliet may be longer

Interestingly, iso-read accepts the correct filename.  Alas, if you don't get the correct filename from iso-info you don't know it and cannot give it to iso-read.

How did bisection work?  Non-trivial, as all too often.  Other than the usual dealing with cleanup in order not to prevent the next git operations, and the usual finding what is the right condition, there was one more detail:  Commit 3b933bb had disabled Rock Ridge, not to be fixed until commit c8d044e, so the appearance of this defect was hidden from bisect in a phase of no Rock Ridge.  The solution was a line in the bisect helper that enabled Rock Ridge before building, so this defect could be detected.

Note that because of apparently necessary use of git clean -fxd the attached bisect-helper-2.sh must be outside (e.g. a sibling) of the libcdio directory, it cannot be in it.  Hence to be invoked by e.g. git bisect run ../bisect-helper-2.sh.

While this bisect-helper-2.sh was essential in finding the source of the defect, it won't make a good permanent test case because of the size of the .iso file.