Hi,
Just gonna point out that I applied my own custom patch for multiextent
files in the custom libcdio version I use in Rufus.
I am *not* planning to post a reworked version of this patch for
libcdio, as I don't think there exists a good solution that can work
without breaking backward compatibility.
Basically, the solution I went with relies on assuming that multiextent
parts of the same file will always be consecutive (but it will at least
warn if that is not the case). In other words, it expects that ISO-9660
mastering tools will always produce something like 'file1.bin [part 1];
file1.bin [part 2]; file1.bin [part 3]; file2.bin; file3.bin' and not
'file1.bin [part 1]; file2.bin; file1.bin [part 2]; file3.bin; file1.bin
[part 3];'
With this in mind, the idea is to redefine the iso9660_stat_s struct to
use fixed size arrays for lsn, size, and secsize, along with a new
uint64_t total_size that keeps track of the accumulated size.
These arrays are set to track up to 8 multiextent parts (a limit defined
in a new ISO_MAX_MULTIEXTENT constant), and the number of actual
multiextent used is also tracked with a new 'extents' attribute [1].
Once we have this redefined struct, we alter the code to ensure that it
is fed it back to _iso9660_dir_to_statbuf() as a new parameter, for as
long as our iso9660_dir_t struct has the ISO_MULTIEXTENT flag set, so
that each of the relevant array element can be set. Then we use the last
part (which doesn't have the ISO_MULTIEXTENT flag) as the one
iso9660_stat_s struct that applies to the multipart file [2].
Obviously, the end result of the 2 basic changes above means that we
need to alter every section of code that dealt with lsn, size, and
secsize (though, when dealing with root or directory elements, we can
safely assume that there's only one multiextent, and therefore use array
element 0 in the same fashion as the non-array attribute was used before
the patch), as well as the various loops that called on
_iso9660_dir_to_statbuf(), either directly or indirectly (rest of the
changes from [2]).
Now, the backward compatibility breakage can be illustrated at [3],
which is the code I use in Rufus to call into the libcdio library, as,
for instance, the writing of an ISO-9660 file must be altered to loop
through the whole extents array for all the sequences of LSN's it needs
to read from. But short of assuming that the LSN's from multiextent
parts will not have any gaps, which I'd be weary to do (I already have
limited worries about not supporting interleaved multiextent files in
this patch, which I suspect mastering tools are unlikely to produce, but
which are still technically possible), I don't see a good
backward-compatible solution to bring multiextent ISO-9660 support to
libcdio...
Regards,
/Pete
[1]
https://github.com/pbatard/rufus/commit/44c9cb0b826a9cf6bd1ed7a251aa731285d83e41#diff-6f29286d9c0e18117d7e377706c5b26d
[2]
https://github.com/pbatard/rufus/commit/44c9cb0b826a9cf6bd1ed7a251aa731285d83e41#diff-18f83593aa6246552193649d6ae07528
[3]
https://github.com/pbatard/rufus/commit/44c9cb0b826a9cf6bd1ed7a251aa731285d83e41#diff-7e747e4f3823e5b688109c3d2105d760
