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