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

[Natalia Portillo]

Hi Pete,

If you create an interesting tool and/or structure specification whatever, YOU 
CANNOT create the wikipedia page yourself, it is considered original research 
and will be queued for deletion per their rules.

I'm in the same situation having done DiscImageChef and the only known reverse 
engineering and documentation of the Lisa filesystem.

Basically you need another person, that can't be related to you directly (not 
your friend) to write the article even if the references are to your website or 
source code.

Sent from my iPhone

> On 25 Jul 2017, at 10:58, Thomas Schmitt <address@hidden> wrote:
> 
> 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
> 
>