Similar to 40138 this could become tolerable if iso-info is able to output a line whether Rock Ridge is present in an .iso file.

If Rock Ridge is present then we could with confidence run iso-info --no-joliet -f (or -l) to avoid long name problems.

Just like the new line showing Joliet level shows 0 if no Joliet, rather than skipping that output line, a line showing Rock Ridge should show 0 or 1, or no or yes. Point is in either case to show a line indicating absence or presence of Rock Ridge, explicitly false or true, so code using iso-info doesn't have to look at the iso-info version number to interpret whether an absent line means no RR.

It would be OK to show any and all "kind of directory info stored in .iso file" info only when iso-info is given a command line option (e.g. -k), told to be verbose / debug, etc.

But it is OK to roll it into normal iso-info output (both for short summary for the whole disk / and or file listing).

The main idea is: If code can tell from iso-info output whether a disk (a typical Linux distro .iso) has Rock Ridge, then it can with confidence invoke iso-read --no-joliet -f (or -l).

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.