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 14:50, Thomas Schmitt wrote:
> > 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).
>
> ECMA-119 contains statements which make sense only if non-aligned
> extents are allowed to exist:

Yes, that's why I said "assumption" above, which I agree is most likely 
wrong and indeed needs to be addressed, as you correctly pointed out.

> > we should assume that there can be gaps between extents,
>
> Indeed the specs promise no gaps only for the directory records.

Okay. In that case I am reluctant to remove the inner loop, even as an 
intermediate stopgap solution until we devise something better, as I see 
an image with a non sequential series of extent a lot more likely to 
exist either currently or in the future, than one with, say, more than 8 
extents.

My biggest issue here is that, unless we store our extent LSNs 
somewhere, we have no means of reporting to users that our assumption 
was wrong, which is a big NO_NO.

Again, while it may look to some that I am cavalier about assuming we'll 
never see a real-life image with more than 8 extents, it is with the 
explicit safeguard that, should my assumption prove incorrect, users 
will be alerted to it through an error message. There is an explicit 
check for that in my proposal.

On the other hand, I'm not sure how we can ever alert our users that our 
assumption of sequential & full block is wrong, unless we store the 
start LSN and size of each extent... in which case, we might as well get 
to process that data with an inner loop altogether, since it doesn't 
cost us much.

The other potential approach I can envision to try to detect that, of 
trying to match an amount of bytes read with a total_size doesn't seem 
very workable to me either.

> But
> i'd say scattering the extents of a file over the ISO makes as little
> sense as having extents of unaligned size before the last extent.

I agree. It makes little sense, and we should expect that *nobody* will 
ever do that.
But if somebody actually does, we won't be able to tell. And that is a 
deal breaker.

> Betting on nicely recorded ISO extents would avoid the problem of having
> an ISO_MAX_MULTIEXTENT limit.

That would be a "blind" bet, unless we add code to hide struct elements 
that, IMO, we should publicise if we have them.

> This would make it a long lasting solution until mad ISOs appear.
>
> I would support such a decision if it is done after due consideration
> of its potential drawbacks.

Silent failure is not an option in my book, so if we go with this, and 
we push for modifying struct iso9660_stat_s as little as possible, we'll 
need to figure out a way to hide an series of LSNs and extent sizes that 
we can validate internally. This looks like a lot of unneeded complexity 
when we can just make them public in the struct.

I very much agree however that my earlier proposal, with the public 
attributes, was lacking detection of non alignment, and that it would 
need to be fixed for that.

> One could adapt Pete's proposal to not bail out if ISO_MAX_MULTIEXTENT
> is exceeded, but to rather continue counting bytes in .total_size
> without recording the surplus extents. A flag in the result should then
> indicate whether .extent_lsn and .extent_size are incomplete.
> So oversized files would be readable if the ISO is neat.

Well, if we go with that proposal, I don't think we need 
ISO_MAX_MULTIEXTENT at all, since total size is the only thing we care 
about, and we wouldn't be storing arrays of LSNs and extent sizes in the 
first place.

So, of course, if the ISO is neat, we're always good.
But if the ISO isn't, we're also going to pretend we're good, when we 
shouldn't...

Then again, maybe you have devised a good solution that'll allow us to 
have the best of both worlds (i.e. assume that we have nicely set up ISO 
*AND* produce an error if it isn't), in which case I'd have no objection 
to go with that proposal, since that the same kind of stuff I've been 
advocating when it comes to ISO_MAX_MULTIEXTENT...

Regards,

/Pete