Hi, Tim Kientzle: > Hmmm.... Are you working with libarchive 2.8.4?
Yes. That is what Debian installed when being asked for bsdtar. > 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. Argh ? All effort in vain ? Well, Debian has xorriso-0.5.6 of May 2010. Six releases behind. If the situation is similar with libarchive ... (cough). > I don't recall libarchive requiring all directories to precede > all files Content block address is the key by which heap_add_entry() sorts files into the sorted list. This list is iterated by next_entry() in read_entries(). If a directory is encountered then its children get inserted into the tree. This iteration loop ends as soon as non-directory is encountered. So, to get a complete list, all directories have to be iterated before any non-directory comes out of next_entry(). > I recall a bunch of test cases over the last couple of years > dealing with various kinds of empty content. If the test images were from mkisofs or genisoimage then it is no wonder. The ECMA-119 entries which carry Rock Ridge symbolic links get a block address in the same range as non-empty data files. I.e. a heap_add_entry() key that is higher than any directory key. The ECMA-119 entries produced by libisofs for symlinks bear block address 0. So the first link appears very early in the iteration. The list then contains only the files from the root directory. And more is not restored to disk. > CC: Michihiro, who has been doing a lot of work in > this part of libarchive recently. The Cc: list gets longer and longer :)) Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
