[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.
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
- [Libcdio-devel] Split libiso9660 into its own project? (Was Re: [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB), Rocky Bernstein, 2018/07/08
- Re: [Libcdio-devel] Split libiso9660 into its own project? (Was Re: [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB), Pete Batard, 2018/07/08
- Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB, Thomas Schmitt, 2018/07/09
- Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB, Thomas Schmitt, 2018/07/09
- Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB, Rocky Bernstein, 2018/07/09
- Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB, Pete Batard, 2018/07/09
- Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB, Thomas Schmitt, 2018/07/09
- Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB,
Pete Batard <=
- Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB, Thomas Schmitt, 2018/07/09
- Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB, Pete Batard, 2018/07/09
- Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB, Thomas Schmitt, 2018/07/09
- Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB, Pete Batard, 2018/07/09
- Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB, Thomas Schmitt, 2018/07/09
- Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB, Pete Batard, 2018/07/09
- Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB, Thomas Schmitt, 2018/07/10
- Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB, Rocky Bernstein, 2018/07/10
- Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB, Pete Batard, 2018/07/10
- Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB, Thomas Schmitt, 2018/07/10