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
