Hi, maybe ritual suicide would have been better than an attempt on iso9660_statv2_t. The diff is now 2600 lines long and i'm not done yet with all examples and test programs. Some housekeeping aspects still need attention, too. (Especially annoying was the habit in rock.c to use iso9660_stat_t as currency where its own iso_rock_statbuf_t would suffice. I had to wean it.)
--------------------------------------------------------------------- During tests of the new code i had to learn that my commit "Hid ISO_MAX_MULTIEXTENT from public and made extent list dynamic memory" http://git.savannah.gnu.org/cgit/libcdio.git/commit/?h=ts-multiextent&id=3b602d69cb116a297ee95e48471a097ce7456435 causes memory corruption (e.g. in example/extract with a Debian netinst ISO) by two clone gestures at the beginnings of _fs_stat_traverse() and _fs_iso_stat_traverse() , which i did not recognize as such. Further the previous programmers caused memory leaks with disposal of iso9660_stat_t objects by free(3) rather than iso9660_stat_free(). In the current implementation this is problematic only with Rock Ridge symbolic links. But with dynamically allocated extents or with iso9660_statv2_t it became bad with every statbuf object. Three cheers to valgrind ! If there is interest, then i can fix this flaw in the ABI incompatible but much less intrusive variation. It depends how my proposal with iso9660_statv2_t is received. (Currently my git clone is clogged with code changes and experiments. I better do not try what happens if i branch now.) Have a nice day :) Thomas
