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

[Thomas Schmitt]

Hi,

(starting of the new mail thread fell victim to
 self-sabotage.) 

-------------------------------------------------

> 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)?

The BSDs have problems with anything about ISO 9660
that was invented after 1990.
Solaris still calls ISO 9660 "High Sierra" ...

If one uses xorriso for serious backup and those systems
are foreseeable restore targets, then one should prepare
a conservative ISO which contains a suitable GNU xorriso
binary, so that the system flaws can be circumvented at
restore time. (I.e. reconstruct system, copy xorriso binary
to system, use xorriso to access the user data in ISO 9660.)


> > 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.

I am testing a remedy now, which hopefully makes less
new trouble than the problem which it avoids.


Some reasoning:

It would cause undesired effects at restore time if
i declared hardlink representation and content deduplication
to be the same thing.
The actual problem is at image production time.
So instead of faking hardlink relations at load time,
libisofs needs an improved comparison function for the call
    ret = iso_rbtree_new(iso_file_src_cmp, &(target->files));
which sets up Vreixo's red-black tree for content
deduplication.

Math calls for a total ordering relation: 
antisymmetric, transitive, applicable to any pair of
file source objects.
The pitfalls are in transitivity. So easy to break
as soon as the comparison function gets complicated.

There were code snippets around in libisofs which
looked promising. I hope i don't shoot my foot now ...


Have a nice day :)

Thomas