Re: [Libcdio-devel] libcdio tools cannot read multi-exent files with Joliet exensions on

[Pete Batard]

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

Regards,

/Pete


[1] 
https://lists.gnu.org/archive/html/libcdio-devel/2018-06/msg00001.html, 
which

On 2022.06.25 11:05, Thomas Schmitt wrote:
> Hi,
>
> 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
>    
> http://git.savannah.gnu.org/cgit/libcdio.git/commit/?h=joliet_multi_extent&id=4c840665c6d9cf2ff1cf0cd12f91b25030776c74
>
> 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) {
> by
>    } 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
> reported.
>
> 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
> disabled.
> 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 :)
>
> Thomas