Hi, after some more calories and sleep i now see two problems in libarchive:
- ISO 9660 images can be read in a single pass only if the directory entry of any file is stored at a lower address than the file's content. This makes multi-session image unsuitable for libarchive. No workaround seems possible. - The implementation of the ISO image reader assumes that all directories come before any data file content. This assumption fails with "flyisofs" images which are elsewise the ideal counterpart to libarchive. They get produced in a single pass. The assumption also fails with libisofs symbolic links and empty data files, which have dummy content addresses. So my proposals for libarchive are: - Detect address pointers which refer to blocks which have already been read and forgotten. This could happen while building the tree. I cannot spot such a test and error message yet. Senseful reactions would then be to abort or to skip the offending file or directory tree. - Become able to process directories and other files in mixed order. This is not easily done but i see no fundamental obstacle with the single-pass constraint. - Map eventual keys in the range of [0 , address_of_volume_set_terminator] to the file's directory's key plus one. The end address of the interval would be recordable in the function isVDSetTerminator(), which is known from bug#610781. It is called before any files get read. A file with address in that interval will never need to read content from there. Surely promised. As for libisofs avoiding the 0 keys: The zeros for symbolic links and device files are written since libisofs.so.6 was founded by Vreixo Formoso in autumn 2007. For empty data files the address of the Volume Descriptor Set Terminator is used since revision 732, 25 Nov 2010. This was in the course of boot experiments for future Debian images. I find no hint, though, that this was necessary to make the experiments succeed. It looks rather like a little overhaul instigated by suboptimal error behavior with an empty boot image file. (There are no empty data files in the Debian image.) It would be more or less harmless to revert the change of rev 732, but to give non-zero addresses to links and device files will put in question the hoarded xorriso testing of 3 years. So in any case, this can be made only a non-default option in xorriso. I will go for such an option, but it may last a few days. Debian CD production should sincerely weigh pros and cons of using it. (I can can give few advise about the risk.) As said, it would not be necessary if libarchive would change the implementation of read_entries() so that it can stand a mix of directories and files, and would map dummy addresses to the directory key + 1. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
