[Top][All Lists]

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

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

From: Pete Batard
Subject: Re: [Libcdio-devel] libcdio treats a >4GB ISO-9660 file as 2 separate parts
Date: Thu, 14 Sep 2017 20:34:11 +0100
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0


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



[1] [2] [3]

reply via email to

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