Re: [Bug-xorriso] shared file content with -indev -> -outdev (form from "Re: bug with handling symbolic links")

[Joerg Meyer]

Hi Thomas,

> RRIP-1.10 has no
> file serial numbers in it, RRIP-1.12 has. For
> compatibility reasons, RRIP-1.10 is written by default.
> If -hardlinks is "on", then RRIP-1.12 is the default
> (if not overridden by -compliance "old_rr").

So if I had (re-)added -compliance "new_rr" when dissecting -for_backup,
I would not have stumbled into this problem.
This makes me wonder: Is there still any need for sticking to RRIP-1.10 by 
default
(i.e. any reasonably up-to-date platforms that cannot cope with 1.12)?

> I will have to rethink how much of the old fallback
> computation for inode numbers can be revived.
Thanks for the explanation - I will happily reprocess that DVD afterwards.

Best wishes,
Jörg.



Begin forwarded message:

> From: "Thomas Schmitt" <address@hidden>
> Subject: Re: bug with handling symbolic links?
> Date: 7 Mar 2015 22:20:24 GMT+1
> To: address@hidden
> Cc: address@hidden
> 
> Hi,
> 
> i start a new thread for the bug that -indev -outdev
> image production represents shared file content from
> the input image as separate content copies in the
> output image. Thus enlarging image size.
> 
> Well, it happened between xorriso-0.2.8 and 0.3.0 in
> autumn of 2008. That's between libisofs-0.6.10 and
> libisofs-0.6.12 and quite exactly the time when
> maintainership of libisofs wandered from Vreixo to me.
> Could well be the first bug i ever planted there.
> 
> There is a trace in the bug tracker:
>  http://libburnia-project.org/ticket/144
> 
> The current code equips ISO nodes with new unique
> inode numbers if they do not bring their own file
> serial number by their Rock Ridge PX entry.
> There are two versions of PX. RRIP-1.10 has no
> file serial numbers in it, RRIP-1.12 has. For
> compatibility reasons, RRIP-1.10 is written by default.
> If -hardlinks is "on", then RRIP-1.12 is the default
> (if not overridden by -compliance "old_rr").
> 
> So the lack of -hardlinks "on" with the original
> ISO production run led to an ISO where hardlinks
> are not indicated by inode numbers.
> 
> In this case, the libisofs code before ticket 144
> fabricated inode numbers from the block address of
> the file data content.
> At that time libisofs had the habit to give empty
> files the same block address as neighboring files
> with data. The identical inode number made them
> hardlink siblings.
> After ticket 144, the unnumbered nodes get unique
> new numbers when the ISO image is loaded.
> 
> 
> I will have to rethink how much of the old fallback
> computation for inode numbers can be revived.
> 
> 
> Have a nice day :)
> 
> Thomas
>