Re: [Libcdio-devel] Rock Ridge and libisofs/xorriso 'AL' extension

[Thomas Schmitt]

Hi,

the directory records of the bug inducing ISO does not have an "SP"
entry. So it is not equipped with SUSP and thus not with Rock Ridge.
The "SP" SUSP entry has to appear in the "." directory record
of the root directory.
SUSP 1.12, 5.3:

  "The "SP" System Use Entry is mandatory. The "SP" System Use Entry shall
   be recorded starting in byte position one (BP 1) in the System Use field
   of the first Directory Record of the root directory of each Directory
   Hierarchy (see ISO 9660:6.8.2) in which the System Use Sharing Protocol
   is utilized, unless the disc is a CD-ROM XA disc, in which case the "SP"
   System Use Entry shall be recorded starting in byte position 15 (BP 15).
   Only one "SP" System Use Entry shall be recorded within a single
   Directory Hierarchy."

libisofs in fs_image.c:read_root_susp_entries() checks for "SP" in "/.".
It seems not to check for the Microsoft pet of CD-ROM XA.
(Joliet prescribes XA for multi-session. Some people interpret this as
 a prescription of ISO 9660 / ECMA-119, which it is not.)


In
  http://git.savannah.gnu.org/cgit/libcdio.git/tree/lib/iso9660/iso9660_fs.c
i see no check for SP, but rather a preprocessor macro:

   int  i_rr_fname =
#ifdef HAVE_ROCK
      get_rock_ridge_filename(p_iso9660_dir, rr_fname, p_stat);
#else
      0;
#endif

The only thing that seems to prevent inappropriate hopping along the
non-present SUSP entry chain seems to be in
  http://git.savannah.gnu.org/cgit/libcdio.git/tree/lib/iso9660/rock.c

  if (!p_stat || nope == p_stat->rr.b3_rock) return 0;

I see rr.b3_rock set in
  http://git.savannah.gnu.org/cgit/libcdio.git/tree/lib/iso9660/iso9660_fs.c

  p_stat->rr.b3_rock = dunno; /*FIXME should do based on mask */

The function  iso9660_have_rr()  seems to traverse the whole directory
tree in order to find SUSP or RR entriees,
But i cannot recognize where it or its subordinates would test for
"SP" or other SUSP+RR entires and set .b3_rock to anything else but
"dunno".

Rocky: Can you confirm my findings in libcdio ?
       (Did i miss something essential ?)


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

Just for completeness i looked at the AAIP aspects of
kali-linux-2017.1-amd64.iso.
Strangely it is a preparation for fast incremental backups:

  isofs.di records device number and inode number of the original file
           on hard disk.
  isofs.st records the timestamp immediately before ISO production began.

Plus an add-on to mark the Rock Ridge name truncation mode which might be
needed to avoid a Linux bug about Rock Ridge name length of 254 or 255
(https://lkml.org/lkml/2015/10/21/270):

  isofs.nt records the Rock Ridge name truncation mode.

It got added because other AAIP entries were already to be added to the ISO.

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

Have a nice day :)

Thomas