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

Submitter:  Leo Baschy <infrastrug>
Submitted:  Sat 28 Sep 2013 08:54:35 AM UTC
   
 
Category:  feature request Severity:  5 - Average
Item Group:  iso-info Status:  Fixed
Privacy:  Public Assigned to:  rocky
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 08 Jun 2014 10:50:38 PM UTC, comment #6: 

Ok. Thanks for the update.

Rocky Bernstein <rocky>
Group administrator
Sun 08 Jun 2014 08:09:32 PM UTC, comment #5: 

No longer known to be a problem in actual use with a variety of .iso files of OS installations.

Also, at least since 0.92 there is an iso-info option --show-rock-ridge (use --help to see details).

Thank you for implementing that.

Leo Baschy <infrastrug>
Wed 04 Jun 2014 07:09:30 PM UTC, comment #4: 

Is this still a problem?

Rocky Bernstein <rocky>
Group administrator
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:


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.

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


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.

Leo Baschy <infrastrug>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #29249:  bisect-helper-2.sh added by infrastrug (1KiB - 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
  • -email is unavailable- added by rocky (Updated the item)
  • -email is unavailable- added by infrastrug (Submitted the item)
  • -email is unavailable- added by infrastrug
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-06-08 rocky StatusNone Fixed
        Assigned toNone rocky
        Open/ClosedOpen Closed
    2013-10-11 rocky Categoryrun-time error feature request
    2013-09-28 infrastrug Attached File- Added bisect-helper-2.sh, #29249
        Carbon-Copy- Added infrastrug

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code