Re: [Libcdio-devel] libcdio treats a >4GB ISO-9660 file as 2 separate parts

[Pete Batard]

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