[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Thomas Schmitt
Subject: Re: [Libcdio-devel] Rock Ridge and libisofs/xorriso 'AL' extension
Date: Tue, 25 Jul 2017 11:58:43 +0200


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.)

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);

The only thing that seems to prevent inappropriate hopping along the
non-present SUSP entry chain seems to be in

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

I see rr.b3_rock set in

  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

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


Just for completeness i looked at the AAIP aspects of
Strangely it is a preparation for fast incremental backups:

  isofs.di records device number and inode number of the original file
           on hard disk. 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

  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 :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]