Sat 28 Sep 2013 08:54:35 AM UTC, original submission:
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
then iso-info -f (or -l) should output a line with
while in fact it outputs incorrectly
Bisection has indicated
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.
|