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

[Thomas Schmitt]

Hi,

i wrote:
> > i noticed that the j-loop assumes full blocks in all but the last
> > extent of a data file.

Pete Batard 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:

 6.4.1 Extent
 An Extent shall be a set of Logical Blocks, the Logical Block Numbers of
 which form a continuous ascending sequence.

 6.4.2 Mode of recording a File Section
 A File Section, [...], shall be recorded in an Extent [...].

 6.4.4.3 Data Space
 The set of Logical Blocks over which the File Section is recorded shall be
 the Data Space of the File Section. [...]"

 6.4.5 Data length of a File Section
 The data length of a File Section shall be the number of bytes in which
 the File Section is recorded in the Data Space. If this number is less
 than the number of bytes in the Data Space, then any remaining bytes in
 the Data Space shall be ignored in interchange. [...]"

How should bytes remain, if not by non-alignment ?
(Plus: Why does Linux prepare for non-alignment ?)


> we should assume that there can be gaps between extents,

Indeed the specs promise no gaps only for the directory records. 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.

Both would be unnatural in the situation of an ISO producer who typically
generates a sequential stream of bytes rather than working by random
access. Creating any gaps between extents of the same file would need
extra effort.


Betting on nicely recorded ISO extents would avoid the problem of having
an ISO_MAX_MULTIEXTENT limit.
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.

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.


But for now i go on with correcting my example loops so that they can
deal with randomly located extents of unaligned size.


Have a nice day :)

Thomas