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

 
 

bug #40138: iso-info trims some filenames

Submitter:  Leo Baschy <infrastrug>
Submitted:  Sat 28 Sep 2013 11:29:56 AM UTC
   
 
Category:  run-time error Severity:  5 - Average
Item Group:  iso-info Status:  Invalid
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

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>
Group 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>
Group 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>
Group 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


fileEightWithARatherUnusuallyLongFilenameButWithSmallishContent.


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 Files:
   
   
Comment:
   

Attached Files
file #29253:  exampleIso1M.iso.tar.gz added by infrastrug (4KiB - application/x-gzip)

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Date Changed by Updated Field Previous Value => Replaced by
    2013-10-10 rocky StatusNone Invalid
        Open/ClosedOpen Closed
    2013-09-28 infrastrug Attached File- Added exampleIso1M.iso.tar.gz, #29253
        Carbon-Copy- Added infrastrug

    Back to the top

    Copyright © 2024 Free Software Foundation, Inc.
    Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
    The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team.
    Page source code

    Powered by Savane 3.13-5884.
    Corresponding source code