Hi, the situation now appears a bit better than first perceived in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610783
The demand of libarchive that all directory entries have to come before any content block eases the task of producing digestible addresses for symbolic links, device files and empty data files. It suffices to let all these files point to an arbitrary block after the directory tree. In the general situation i would have to make them point to their neighbors. A much more ill situation, and also much more demanding towards the current libisofs architecture. If libarchive ever gives up the demand of directories-first, then it will have to compute own suitable keys for the affected file types which have no data content. Another problem would be hard links, which are quite common in ISO images. So my change proposal for libarchive appears more and more cumbersome. The simpler change in libisofs will probably allow me to make it suitable for unchanged libarchive by default. A dedicated block of 2048 zero bytes should avoid any ambiguity with non-empty data files. I am currently testing an implementation sketch which looks quite trustworthy. Another insight: The reason why bsdtar with genisoimage did not create two hard links to vmlinuz is in my Linux. It never shows hardlink siblings in mounted ISO images because it computes the inode number from the byte address of the directory entry. Two entries = two different inode numbers. So ISO images produced from /mnt contain two copies of vmlinuz. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
