Hi,
Pete Batard wrote:
> Use the processed cont_extent to read the relevant continuation block
> into a buffer and then use that block, along with cont_offset and
> cont_size, to carry out further Rock Ridge data processing.
> [...]
> + if (iso9660_iso_seek_read(p_image, buffer, cont_extent, 1) !=
> ISO_BLOCKSIZE)
> + goto out;
> + chr = &buffer[cont_offset];
> + len = cont_size;
Do i get it right that encountering a CE entry causes immediate
continuation of interpretation at the depicted continuation area ?
If so, then this does not obey the specs. SUSP 1.12 says:
The "CE" System Use Entry indicates a Continuation Area that shall be
processed after the current System Use field or Continuation Area is
processed.
So the CE parameters cont_extent, cont_offset, cont_size need to be
buffered until the while-loop has ended. Only then the continuation
area should be loaded and interpreted.
Linux and libisofs do this buffering when interpreting CE. GRUB does not.
mkisofs, genisoimage, and libisofs write CE as last entry, so that GRUB
did not experience problems yet. (I plan to craft a demonstration ISO
and to submit a patch to GRUB.)
--------------------------------------------------------------------
Further:
Consider to implement interpretation of the ST entry, which marks the
end of the SUSP data within a directory record or continuation area.
I.e. it should break the while-loop regardless of the remaining len.
SUSP 1.12 says
If the remaining allocated space following the last recorded System
Use Entry in a System Use field or Continuation Area is less than four
bytes long, it cannot contain a System Use Entry and shall be ignored.
Otherwise an "ST" System Use Entry (see section 5.4) shall be the last
System Use Entry recorded in a System Use field or Continuation Area.
So the current while-loop condition
while (len > 1){ /* There may be one byte for padding somewhere */
could be widened to (len >= 4) ... if i am not off by one.
Have a nice day :)
Thomas
