Hello Thomas! Thanks for your very thorough investigation on this. There are already a couple of bugs in the libarchive bug tracker talking about problems of the streams design of libarchive so I guess this is just another one to put on the pile unfortunately.
I'm adding Tim Kientzle and the libarchive-discuss list to CC. Please note this url in case anyone wants to read up on the entire discussion: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610783 Thomas latest/final analyze included in full below... On Tue, Jan 25, 2011 at 09:36:03AM +0100, Thomas Schmitt wrote: > 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 > > > -- Andreas Henriksson -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
