Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB

[Pete Batard]

On 2018.07.09 11:54, Thomas Schmitt wrote:
> i noticed that the j-loop assumes full blocks in all but the last
> extent of a data file.

I think I'm getting confused here.

To me, for ISO-9660, a "block" or a sector is a 2048 element of data, 
and an extent is made of extent_size[j]/2048 "blocks" (with an 
assumption that the extent_size[j] always being a multiple of 2048 
except for the last block, since it makes little sense otherwise).

> Applications would not need to loop over extents but simply loop
> longer over the blocks of a single giant extent.

How so?

My assertion was that extents can exist at non sequential LSNs, which is 
why I don't think we can avoid the inner j-loop. In other words, we 
should assume that there can be gaps between extents, and therefore that 
we at least need the j-loop to figure out the actual start position of 
our extent.

Am I missing something here? Do the specs explicitly state that extents 
must be sequential?

> The assumption itself is quite plausible.

Yes, I do agree that sequential extents and extent_size[j] being a 
multiple of 2048 except for the last is very plausible.

But if it's not in the specs, then we are going to silently trash data 
on ISO-9660 images that do not follow our assumptions, which is a major 
dealbreaker.

And this is quite different than the "nobody will ever use more than 8 
extent" assumption that I was advocating to go with earlier, because, in 
the earlier case, if we are wrong, then the user will get an explicit 
error, which is fine in my book. But in this case, if we are wrong, we 
will silently copy invalid data and make them believe that everything is 
good.

Or am I missing something with that j-loop removal?

Regards,

/Pete