[Top][All Lists]

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

Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible

From: Pete Batard
Subject: Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB
Date: Mon, 9 Jul 2018 15:43:59 +0100
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.0

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.

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

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



reply via email to

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