Thomas, It will be a day or two before I can dig deeply into this.
Unfortunately, it's been a while since I looked at that part of the code in detail, but I don't recall libarchive requiring all directories to precede all files and I recall a bunch of test cases over the last couple of years dealing with various kinds of empty content. So I suspect the situation is a little less dire than you think. ;-) Hmmm.... Are you working with libarchive 2.8.4? There have been a number of fixes in trunk specifically to handle symlinks and other empty data files; maybe some of those need to be backported. Tim CC: Michihiro, who has been doing a lot of work in this part of libarchive recently. On Jan 25, 2011, at 7:57 AM, Thomas Schmitt wrote: > 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 > > -- > You received this message because you are subscribed to the Google Groups > "libarchive-discuss" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/libarchive-discuss?hl=en. > > -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
