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

[Thomas Schmitt]

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