Incompatibility with recent mkisofs betas

peetz
2012-01-12
2012-12-07
  • peetz

    peetz - 2012-01-12

    Hi,

    I'm using the Windows binaries of recent alpha builds of mkisofs to create ISO files, because these recent builds are able to create multiboot ISOs with (U)EFI boot support.
    However, I cannot unpack ISO files that were created by e.g. mkisofs 3.01-a06 with 7-zip, even if the files were created without any boot support at all. The error message I get is "cannot open file as archive". ISO files that were created by mkisofs-3.00 open fine with 7-zip, but other tools like e.g. UltraISO are also able to open the ISO files created by mkisofs alpha builds.

    mksiofs is available here: http://cdrecord.berlios.de/private/cdrecord.html
    a Windows binary of the latest alpha build 3.01-a06 can be downloaded here: http://home.arcor.de/artemis002/tools/cdrtools-3.01a06-bin-win32.rar

    Does anyone have a workaround or solution for this problem?

    Thanks
    Andreas

     
  • Ady

    Ady - 2012-07-25

    I\'m still using 7-zip v.9.20 stable. I have tested mkisofs win32 ports, for example from

    www.student.tugraz.at/thomas.plank/
    

    . I compared the results of different mkisofs versions, using the same folder origin for the build of the resulting ISO image and the same mkisofs command line arguments and options.

    When using mkisofs 3.00 stable (and older stable versions too), 7-zip correctly opens the resulting ISO image.

    When using mkisofs 3.01a07 (alpha), 7-zip fails to open the resulting ISO image with:

    cannot open file as archive

    .

    I initially thought that the problem was the alpha versions of mkisofs, but then every other tool I used indeed opens or uses the resulting ISO image correctly. Such tools include izarc and virtualbox, among others.

    I'm not saying there is a bug in 7-zip, but it would be helpful if the user at least could have some method to find out what exactly is the "problem" for 7-zip to open such ISO image. Since other tools are opening and using them, it is certainly not a "show-stopper" type of problem or incompatibility.

    Which "non-standard code" in those ISO images is preventing from 7-zip to open them? Are there any more-specific error messages / debug log the user could access? In such case, how to generate them in these particular cases and where to look for them?

    Maybe this issue is already resolved in newer 7-zip versions after the current v.9.20 stable?

    If there is a need for more info, please let me know.

     
  • Igor Pavlov

    Igor Pavlov - 2012-07-25

    Try 7-Zip 9.28 alpha version.

     
  • Ady

    Ady - 2012-07-25

    I have now tested 7-zip 9.28 alpha. It's the same as before with 9.20; the issue persists :(.

    BTW, there should be a portable edition for 7-zip beta (or alpha) available for download, so the user would be able to still keep the current stable version installed without any conflicts.

    Igor, may I suggest…?. You should try building any simple ISO image with mkisofs 3.0 stable and the same ISO image with 3.01a07, and then try opening both with 7-zip.

    Let me know if you need more info.

     
  • Igor Pavlov

    Igor Pavlov - 2012-07-26

    Can you create example of such ISO and upload to some server?

     
  • Ady

    Ady - 2012-07-26

    The following 7z archive includes 2 ISO images for you to compare.

    NAME : mkisofsdiffiso.7z
    SIZE : 3359071 bytes (3.2MiB)
    MD5 : B955EE5F02C0E1FE841B99A03844CDD9
    SHA1 : 5749A8CF567E5AA68C6820B9932D9E06EED281F1
    SHA256 : 435D0665EA3D649F5E861DE2800BE3D2E8101F0015E9DA8E50BF103C502C10BB
      NOTE: Replace "wXw" with the correct "www" to download:
    DOWNLOAD : wXw.fileconvoy.com/dfl.php?id=g75fa1fac6dd5786413247606aae21ad7a1eec1
    

    The file will be available for the next 7 days.

    Let me know if you need more details.

     
  • Igor Pavlov

    Igor Pavlov - 2012-07-26

    Data in "Creation Date and Time" field of "Volume descriptor" is incoreect (it contains spaces).

    Ecma-119.pdf:
      8.4.26 Volume Creation Date and Time (BP 814 to 830)
      This field shall specify the date and the time of the day at which the information in the volume was created.

    You can send BUG report to mkisofs developers.

     
  • Ady

    Ady - 2012-07-26

    Thank you Igor.

    Are you saying that mkisofs 3.00 stable correctly builds the data in the "Creation Date and Time" field of "Volume descriptor", but the newer 3.01a07 alpha builds it INcorrectly?

    Let me ask you the question using different words. Is this specific property ("Creation Date and Time" field of "Volume descriptor") the one and only issue that is preventing 7-zip from opening the ISO image? Please confirm that I am correctly understanding your report.

    In any case, why 7-zip completely discards the possibility of opening (or extracting) such ISO image? I mean, for the functions included in 7-zip regarding ISO images, is there any difference if the "Creation Date and Time" field of "Volume descriptor" contains spaces, or instead contains valid values? Why 7-zip even cares about this specific characteristic of the ISO image?

    I agree that the ISO standard (Ecma-119) should be respected by mkisofs, but I don't see a reason for 7-zip to completely refuse opening the ISO image just because such specific property (field) is not being correctly built (by mkisofs).

     
  • Igor Pavlov

    Igor Pavlov - 2012-07-27

    Yes, you can see the difference in hex editors, if you open both ISO files.
    Probably 7-Zip doesn't see any other error in that ISO.
    7-Zip decoder just follow standard. It's good that 7-Zip checks such errors.
    Probably it could show warning in that case. But that error is so infrequent (I didn't see ISO archives with such error before), so I don't want to change that  code.

    Write to mkisofs developers.

     
  • Ady

    Ady - 2012-07-28

    Yes, you can see the difference in hex editors, if you open both ISO files.
    Probably 7-Zip doesn't see any other error in that ISO.

    Thank you Igor. Using a hex editor I edited each of the problematic ISO images, each in 3 different offsets. At each offset, I replaced the blank spaces ( 0x20 ) with 17 adequate hex values representing the "Creation Date and Time" values. The new resulting ISO images were correctly opened by 7-zip.

    7-Zip decoder just follow standard. It's good that 7-Zip checks such errors.

    I agree that the standard should be followed by all ISO related software, and in this case 7-zip, and specially you, helped find out the bug in mkisofs alphas.

    Probably it could show warning in that case.

    That was my suggestion. Following the standard is what should happen, so 7-zip is correct in that regard. Yet, ideally, 7-zip could provide either a warning or information about such "non-stoppers" characteristics (in "info" or "properties" or similar function), and still let open the ISO image.

    But that error is so infrequent (I didn't see ISO archives with such error before), so I don't want to change that  code.

    I understand your point. Please at least consider adding this possibility in the future (adding this as a feature request or TODO list). I don't mean specifically for this data field in particular, but in general for archives that may not follow the relevant standard as strictly as they should, but that the info inside the archive is still readable.

    Write to mkisofs developers.

    I am reporting this BUG to mkisofs' ( cdrtools' ) developers. Thank you very much.

     
  • Ady

    Ady - 2012-08-16

    Just an update.

    This bug in mkisofs was introduced in version 3.01a05 and was also present in -a06 and -a07 too.

    This (regression) bug was resolved in mkisofs (part of cdrtools) 3.01a08. So the corresponding 7-zip \\\"bug report\\\" at

    sourceforge.net/tracker/index.php?func=detail&aid=3473070&group_id=14481&atid=114481
    

    can be closed.

    Thank you Igor for your help.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks