[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libcdio-devel] libcdio tools cannot read multi-exent files with Jol

From: Pete Batard
Subject: Re: [Libcdio-devel] libcdio tools cannot read multi-exent files with Joliet exensions on
Date: Sun, 26 Jun 2022 01:03:18 +0100
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0

Hi Thomas,

I can confirm that your patch solves both the issues I was seeing in Rufus. Not too sure why you jumped on taking the blame for introducing the issue, as I'm pretty sure I'm the one who did when I thought that we'd always had valid ISO9660 names when dealing with multiextents, and can point to the comments going that way in the first proposal at [1] (from which I believe the subsequent proposals were derived).

Also, I haven't analysed the isolinux error report to a great extent, but it looks to me that, because of the name screwup, we're ending up trying to process a multiextent part that does not belong to the isolinux/ directory while we're traversing that directory, hence the report.

At least, what a quick debug session with the problematic code showed me in Rufus is that the "Bad directory information for isolinux" is a direct consequence of getting a "Non consecutive multiextent file parts for ''" when calling _iso9660_dir_to_statbuf() while we're traversing isolinux/ and getting a NULL p_stat as a result. So, indeed, if you fix the consecutive multiextent error, then you fix the isolinux error, even though at first glance those two seemed unrelated.

At any rate, your patch looks good to me, so thanks a lot for investigating and producing a fix so quickly!

I have validated that, once applied to Rufus, it can create media from the Gentoo image without issues, so I'll integrate the fix for the 3.19 release... though, and this is mostly addressed at Ben, this still doesn't result in a media that boots Gentoo properly because, even though the Gentoo people did make sure that they placed a duplicate of the ESP image content on the ISO file system structure (Now, wouldn't it be *nice* if xorriso did that on its own... ;)) and that their build of GRUB 2.0 does include the ntfs module (Props to the Gentoo maintainers for thinking about doing that), it looks like the boot kernel is still missing an NTFS driver, which ultimately prevents the installer from being able to mount the media and proceed...

That's actually the curse of having to contend with files that are larger than 4 GB in your installation image: Besides running into issues with poorly written multiextent support (which I'll happily take the blame for), you also have to pretty much add support for NTFS every step of the way unless you're content with restricting your users to duplicating your media with dd only, since NTFS is becoming the de-facto replacement file system for when FAT32 is no longer suitable...



[1], which

On 2022.06.25 11:05, Thomas Schmitt wrote:

i pushed a new branch "joliet_multi_extent" with a single commit

   Bug fix: Recognition of multi-extent files was broken if Joliet is present

A new function _iso9660_recname_to_cstring() implements the conversion
which _iso9660_dir_to_statbuf() now needs at three occasions.
It can allocate the memory for the result string or put it into a
submitted memory area. (I doubt that both modes together make sense.)

A cosmetic change was to equip the recognition of "." and ".." with
curly brackets so that i could replace
   else if (u_joliet_level) {
   } else {


I began to explore the
   "Bad directory information for isolinux"
problem, which Pete Batard reported.

The commited code lets iso-info report properly and without warning the
content of Gentoo's livegui-amd64-20220605T170549Z.iso

I then took my provisory fix of yesterday and blocked the recognition
of u_joliet_level in both new occasions.
This yielded an endless stream of "." and ".." filenames. Not what Pete

But if i only disable one of the two new Joliet name recognitions, i get
the "Bad directory information for isolinux" message and a similar one
about directory "/snapshots". It does not matter which of the two i keep
The same happens if i checkout branch "master" and compile it.

So i looks like i fixed this too, but without fully understanding what
was wrong initially.

Have a nice day :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]