Re: isofs hardlink bug (inode numbers different)

[James Pearson]

>> I am trying to back up directory trees on CD, preserving hard links.
>> newer versions of mkisofs are supposedly able to do this, but although
>> the data is written to the isofs only once, the resulting directory
>> entries have differing inode numbers thus making restore operations
>> impossible.
>> 
>> When I sent a bug report to the author of mkisofs, Jörg Schilling, I
>> got the reply
>> 
>> >>mkisofs 2.01a01 (i686-pc-linux-gnu)
>> >>mkisofs 2.0 (i686-pc-linux-gnu)
>> >>mkisofs 1.15a27 (i686-suse-linux) 
>> >>Google shows no reference to anything which tells me that this is not
>> >>supposed to work, therefore I assume it's a bug.
>> >
>> >Nachdenken hilft wie in vielen Fällen auch hier:
>> >
>> >Der Bug auch hier ist da, wo es wegen schlechter SW Qualität wahrscheinlicher
>> >ist: Im Linux Kernel.
>> 
>> (Translation: thinking helps here too, like in many other cases: the bug
>> is in the linux kernel, where it is more likely to be due to lower
>> software quality.)
>
>[FWIW, Jörg is well-known for thinking that anything that isn't
>Solaris is complete crap.  He's entitled to his opinions.]
>
>> Insults aside, is it true that the kernel's isofs can't produce correct
>> inode numbers for hardlinked files? If that is the case it would
>> somewhat reduce the usefulness of isofs for backups.
>
>It's sort of true.
>
>There are inode numbers stored in RockRidge attributes, but using them
>comes with some humongous caveats:
>
>First: You have absolutely no guarantee that they are actually
>unique.  Broken software could easily have written them with all
>zeroes.
>
>Second: If there are files on the CD-ROM *without* RockRidge
>attributes, you can get collisions with the synthesized inode numbers
>for non-RR files.
>
>Third: If you actually rely on inode numbers to be able to find your
>files, like most versions of Unix including old (but not current)
>versions of Linux, then they are completely meaningless.
>
>The basic problem is that the RR attributes are arbitrary numbers,
>instead of any kind of pointer saying "I'm a hard link to this other
>file over here."
>
>There is another way to generate consistent inodes for hard links,
>which is to use the data block pointer as the "inode number."  This,
>however, has the problem that *ALL* zero-lenght files become "hard
>links" to each other.

In fact, for isofs file systems created with mkisofs, zero length files
would be hard links to the next file with data written to the CD.

You would also have the problem that there is nothing to prevent files
with different owner, permissions, dates, etc. sharing the same file data
...

James Pearson