Re: [Bug-xorriso] bug with handling symbolic links?

[Joerg Meyer]

Hi Thomas,

>> I am wondering now whether this 
>> 
>>       xorriso -for_backup \
>>               -indev /dev/sr0 -outdev test-rebuild.iso \
>>               -joliet on -volid test-rebuild \
>>               -commit_eject all
>> 
>> would be a proper first test (now with 1GB RAM ;-).
> 
> For the SUSP/RRIP entries, yes.
Indeed, the resulting ISO is "isovfy-error-free"!

> The new production run is supposed to keep those files
> together which share the same data content blocks in
> the input image. 
Hmm, the output image is too large by an amount that corresponds nicely to the 
deduplicated data.
Omitting -for_backup produces (up to a few 100kB) the same file size.
Having a closer look yields 

address@hidden xorriso-tests]# isoinfo -i test-rebuild.iso -R -l  | grep ginit
-rwxr-xr-x   1    0    0         1893784 Jan  1 1970 [2560671 00]  ginit
-rwxr-xr-x   1    0    0         1893784 Jan  1 1970 [2561596 00]  ginit

in both cases whereas the original DVD has

address@hidden xorriso-tests]# isoinfo -i /dev/sr0 -R -l  | grep ginit
-rwxr-xr-x   2    0    0         1893784 Jan  1 1970 [1215076 00]  ginit
-rwxr-xr-x   2    0    0         1893784 Jan  1 1970 [1215076 00]  ginit

If I understand correctly, hardlinks are not imported or kept from the input 
then.
Is there another flag that is supposed to enforce this?

>> the "troublemaker symlinks" are not accessible:
>> [...]
>> Those based on your first rockridge.{c,h} patch do not show these problems.
> 
> I have to face the fact that my (and Vreixo's) reading
> of SUSP specs is not compliant with the understanding
> of the reader programmers.
> Luckily my workaraound/correction seems to be more
> disgestible for them.
Works great - and results of the "deviating interpretation" are salvageable 
with via xorriso ;-)

Thanks a lot again & best wishes,
Jörg.