[Debburn-devel] A problem about genisoimage

[Thomas Schmitt]

Hi,

i can reproduce the problem with genisoimage-1.1.7.1.
mount(8) shows a truncated filename.
xorriso refuses to load the ISO.
genisoimage complains when reading it with option -M
  $ genisoimage -R -M /dvdbuffer/test.iso some_file >/dev/null
  ...
  genisoimage: Old session has illegal name '1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123' length 193

(My test name on hard disk is 250 characters long.)

The resulting ISO is weird.

Both, the Primary Volume Descriptor (of ISO 9660) and the
Supplementary Volume Descriptor (of ISO 9660:1999) point to
the same root directory extent at block 24. They are supposed
to point to separate trees.

In the data file directory record beginning at byte 49390,
there is only the ISO 9660 info and one SUSP field CE,
which points to block 25 with byte offset 0.
At that position there is an RR field, a NM field with
a size of 253 bytes, and a CE field.
This CE field points to block 0, byte offset 0.

The second CE field makes not much sense, even if it would
point to a useful block address. There is still enough room
in block 25 to store the remaining 2 bytes of the file name
as second NM field.

-------------------------------------------------------------

If i leave out -iso-level 4, then the ISO 9660 part of the
directory record of the data file is shorter, because of the
shorter ISO 9660 name. There is room to record the RR field
and a first NM field of 151 bytes with 146 name characters.
Then comes a CE field which points to block 14, byte offset 0.
There i find a single NM field of 109 bytes with the remaining
104 name characters.
Followed by a PX and a TF field. No further CE.

So i assume that the CE field is issued unconditionally
whenever an NM field is not large enough to take the remaining
name characters.
If this happens in the continuation area, then there is
probably no info prepared, where the next continuation area
shall be allocated. So the block address 0 could sneak in.

The correct reaction on the overflow of NM in the
continuation area would be to record another NM with the
remaining characters. (Rock Ridge specs do not actually limit
file names to 255 characters. But X/Open does not guarantee
more than that at mount time.)


Have a nice day :)

Thomas