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 <[email protected]> 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
