bugCompact Disc Input and Control Library - Bugs: bug #40130, iso-info between .83 and .90...

 
 

bug #40130: iso-info between .83 and .90 started giving bad info in some cases

Submitted by:  Leo Baschy <infrastrug>
Submitted on:  Sat 28 Sep 2013 08:54:35 AM UTC  
 
Category: feature requestSeverity: 5 - Average
Item Group: iso-infoStatus: None
Privacy: PublicAssigned to: None
Open/Closed: Open

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

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

 

Fri 11 Oct 2013 07:05:18 AM UTC, comment #3:

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).

Leo Baschy <infrastrug>
Wed 02 Oct 2013 05:49:57 PM UTC, comment #2:

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:

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

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.

Leo Baschy <infrastrug>
Sun 29 Sep 2013 07:56:02 PM UTC, comment #1:

That specific file from that specific .iso gets listed correctly again (as it used to be in 0.81) when invoking a current iso-info with option --no-joliet.

Leo Baschy <infrastrug>
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.

Leo Baschy <infrastrug>

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #29249:  bisect-helper-2.sh added by infrastrug (1kB - application/octet-stream - bisect-helper-2.sh)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by rocky (Updated the item)
  • -unavailable- added by infrastrug (Submitted the item)
  • -unavailable- added by infrastrug
  •  

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

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 11 Oct 2013 08:38:05 AM UTCrockyCategoryrun-time error=>feature request
    Sat 28 Sep 2013 08:54:35 AM UTCinfrastrugAttached File-=>Added bisect-helper-2.sh, #29249
      Carbon-Copy-=>Added infrastrug

    Back to the top


    Powered by Savane 3.1-cleanup