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

[Thomas Schmitt]

Hi,

i cloned a libcdio git and build it.
Now i realize that "isoinfo" is not a libcdio program. Duh.
So i go on with libcdio's ./src/.libs/iso-info . 

To force linking with the freshly compiled libraries i do:

  export 
LD_LIBRARY_PATH="$(pwd)/lib/iso9660/.libs:$(pwd)/lib/udf/.libs:$(pwd)/lib/driver/.libs"

Then i try with the 50 KB test iso from the bug report:

  ./src/.libs/iso-info -f -i 
/dvdbuffer/libcdio-heapoverflow-get_rock_ridge_filename.iso

It says
  ...
  __________________________________
  ISO-9660 Information
  Error getting above directory information

Is this a known symptom of the problem we deal with ?
Or am i seeing something different here ?

Other ISOs yield a list of files.

I will start with experiments and debugger now.

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

The other user who urges me to record xorrisofs options by default,
showed me a live-build script which indeed has xorrisofs option
--hardlinks.
So i posted a test proposal to
  https://bugs.kali.org/view.php?id=4109
in order to find out whether this is really the trigger which caused the
"AL" SUSP entires in the ISO.


Update: Pete found the same script meanwhile. So it is very likely
the origin of the KALI ISO and its "AL" entries. 

Now i wonder what Raphael intended with the commit that introduced
option --hardlinks for ISOs with SYSLINUX/ISOLINUX bootloader:

  
https://anonscm.debian.org/cgit/debian-live/live-build.git/commit/scripts/build/binary_iso?id=9c974b26bf532ba76f6d66423310f6d95b1ff1f7
  author        Raphaël Hertzog <address@hidden>        2016-12-02 14:42:59 
(GMT)
  "Instead of renaming kernel for syslinux, create hardlinks"

As already stated, my users are more inventive than i am.
(Let me hope this does not rely on a bug or unintentional feature of
 libisofs.)


Have a nice day :)

Thomas