On 2018.07.09 20:01, Thomas Schmitt wrote:
* Old iso9660_stat_t with only additional member .total_size, refusing on multi-extent files with gaps. (I doubt we will find any such files in the wild.) No ISO_MAX_MULTIEXTENT.
I still don't see how that would work unless we assume that all extents except the last are exactly 4 GB. And even then, unless you create new attributes somewhere, I have no idea where you'll pull the LSNs values you need to compare so that you can properly refuse images with gaps.
Unless you can actively detect and refuse multiextent ISOs that libcdio cannot process, this is a NO_GO for me.
* Old iso9660_stat_t with your extents arrays and visible small ISO_MAX_MULTIEXTENT, but erroring out only if ISO_MAX_MULTIEXTENT is exceed and also gaps are detected.
My vote and IMO, the more pragmatic and safe approach.
If only one of these conditions is true, then it would continue to collect the info for the other access method.
If it was me, I'd go for the pragmatic approach here too of just erroring out in both cases for now, and simply wait until someone comes with a real-life scenario where they really have a > ISO_MAX_MULTIEXTENT multi extent ISO, that they must absolutely use with a shared library they can't control, to implement the other access method.
* New iso9660_statv2_t capable of very large extent lists. (I plan to implement array re-allocation in case of overrun. 10,000 extents shall be no problem.)
Congratulation on solving an academical problem... that nobody will ever have in practice, and that libcdio will alert you about anyway, if you do manage to run into it.
Nevertheless a "gapless" flag will indicate to lazy application programmers that they did bet on the right horse.
If I were to venture a guess about "lazy" application programmers, I'd surmise that they are probably going to be a lot more annoyed at having to figure out why libcdio is pushing 2 methods of achieving the same thing than having the ability to bet on a horse.
But then again, as long as none of my development time is being requested, I'm certainly not going to try to discourage you to spend yours as you see fit... ;)
Regards, /Pete
