bugCompact Disc Input and Control Library - Bugs: bug #40138, iso-info trims some filenames

 
 

bug #40138: iso-info trims some filenames

Submitted by:  Leo Baschy <infrastrug>
Submitted on:  Sat 28 Sep 2013 11:29:56 AM UTC  
 
Category: run-time errorSeverity: 5 - Average
Item Group: iso-infoStatus: Invalid
Privacy: PublicAssigned to: None
Open/Closed: Closed

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

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

 

(Jump to the original submission Jump to the original submission)

Thu 10 Oct 2013 03:47:26 PM UTC, comment #7:

What we'd need is for iso-info to also tell whether Rock Ridge is present in the .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.

To my understanding the Joliet level doesn't tell whether Rock Ridge is present.

Leo Baschy <infrastrug>
Thu 10 Oct 2013 12:53:21 AM UTC, comment #6:

> I couldn't find a (simple, scriptable) way to tell whether an .iso file has Rock Ridge and/or Joliet respectively. Is there?


The API had for a long time get_joliet_level(). Recently in git, iso_info shows a non-zero Joliet level detected if Joliet support is compiled in.

Rocky Bernstein <rocky>
Project Administrator
Mon 07 Oct 2013 04:13:10 PM UTC, comment #5:

If Rock Ridge is known to store longer file names (255 bytes), see Wikipedia (ISO 9660, Rock Ridge, etc), then why not if both Joliet and Rock Ridge are present automatically prefer Rock Ridge? This example .iso file has both Joliet and Rock Ridge.

Maybe that is the way it has developed historically. A change, even if logical, might not be worth the effort or risk at this time.

This has lead to a question: I couldn't find a (simple, scriptable) way to tell whether an .iso file has Rock Ridge and/or Joliet respectively. Is there? If I could tell then one could make scripts use --no-joliet in case both Rock Ridge and Joliet are present. Having reservations about the default behavior, one could work around it.

This is low priority, partially because it only has occurred in a constructed test case, not in an .iso we ran into. We could somehow work around it, though not elegantly.

I will not write any more code (beyond the test scripts) for this specific issue at this time.

Leo Baschy <infrastrug>
Sun 06 Oct 2013 09:13:12 PM UTC, comment #4:

> One could argue if the full length name is available in another format, e.g. Rock Ridge, then it should recognize Rock Ridge's is longer than Joilet's limit and display Rock Ridge.


If you want to provide a patch for such a new option to use this kind of behavior, I'll consider it. But I don't think it wise to change the current default behavior unless there is a genuine bug.

Here, I think whatever process created this ISO image truncated that name at 64 characters in the Joliet SVD as it is supposed to do. If that's the case, then is-info when not given --no-joliet is to report what's there as it currently does.

Rocky Bernstein <rocky>
Project Administrator
Sun 06 Oct 2013 08:58:08 PM UTC, comment #3:

One could argue if the full length name is available in another format, e.g. Rock Ridge, then it should recognize Rock Ridge's is longer than Joilet's limit and display Rock Ridge.

In the test case the info is present, and with --no-joliet it displays correctly.

I can agree to this being relatively lower priority.

I think we agree not to break something else because of an attempt to fix this. To allow some more testing (confidence things aren't broken) I have written that extra little script isoimageexperiment.py in NrvrCommander which I mention in bug 40130, it tests complete .iso files with thousands of files, e.g. real distro .iso files. It uses iso-info and then does plenty of iso-read. Of course it is a disk hog if used with a distro .iso. And as coded it wouldn't catch some kinds of bad reads. It merely is good at catching bad filenames from iso-info.

Leo Baschy <infrastrug>
Sun 06 Oct 2013 04:06:15 PM UTC, comment #2:

I'm not sure this is a bug.

<a href="http://support.microsoft.com/kb/142372">http://support.microsoft.com/kb/142372</a> says that filenames can't be longer than 64 characters:

> Joliet allows you to use filenames up to 64 characters in length, including spaces.


Rocky Bernstein <rocky>
Project Administrator
Sun 29 Sep 2013 11:14:26 PM UTC, comment #1:

That specific file from that specific .iso gets listed correctly when invoking iso-info with option --no-joliet.

Leo Baschy <infrastrug>
Sat 28 Sep 2013 11:29:56 AM UTC, original submission:

This is different from bug 40130.

Reproducible: Take the attached .iso, which is a side product from bug 39373, but use the one attached here, to be sure it is the right version, and iso-info -f or iso-info -l it. See the filename

trimmed of its extension, which would be txt.

iso-read works fine with that file.

But, if you don't get the right name from iso-info then one cannot ask iso-read to get the file, if it is an .iso with variable files on it.

Different than other bug in three ways:

1) This bug "never" worked, at least not in 0.81, that's how far I went back. The other one worked before the determined first bad version.

2) This bug looks like a simpler "trim" so the reason might be a simple "max length" or so. The other bug does some fancy trimming in the middle of the name.

3) This bug has been found with a file made for testing. The other bug is from a real world Ubuntu distro .iso, which was working fine in 0.81.

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 #29253:  exampleIso1M.iso.tar.gz added by infrastrug (4kB - application/x-gzip)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by rocky (Posted a comment)
  • -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 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 10 Oct 2013 12:53:21 AM UTCrockyStatusNone=>Invalid
      Open/ClosedOpen=>Closed
    Sat 28 Sep 2013 11:29:56 AM UTCinfrastrugAttached File-=>Added exampleIso1M.iso.tar.gz, #29253
      Carbon-Copy-=>Added infrastrug

    Back to the top


    Powered by Savane 3.1-cleanup