Hi,
I think it is the same thing that I fixed in libarchive trunk/r2940.
xorriso set 0 to the location of symlink files but our ISO reader
uses it to sort all entries in an ISO image to read them in
stream, and the reader expects that all directory entries appear
before any other type of entries. So that set 0 to the location
stops the reading a directory entries.
Could you try the following path against libarchive 2.8.4 ?
Index: libarchive/archive_read_support_format_iso9660.c
===================================================================
--- libarchive/archive_read_support_format_iso9660.c (revision 2945)
+++ libarchive/archive_read_support_format_iso9660.c (working copy)
@@ -1807,14 +1807,17 @@
* NOTE: Old mkisofs did not record that FILE SERIAL NUMBER
* in ISO images.
*/
- if (file->size == 0 && location >= 0)
+ if (file->size == 0 && location >= 0) {
/* If file->size is zero, its location points wrong place.
* Dot not use it for file number.
* When location has negative value, it can be used
* for file number.
*/
file->number = -1;
- else
+ /* Do not appear before any directoy entries. */
+ if (file->offset == 0)
+ file->offset = -1;
+ } else
file->number = (int64_t)(uint32_t)location;
/* Rockridge extensions overwrite information from above. */
Michihiro
2011/1/26 Tim Kientzle <[email protected]>:
> 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]
