Re: isofs hardlink bug (inode numbers different)

[Frank van Maarseveen <F.vanMaarseveen@inter.NL.net>]

On Mon, Feb 03, 2003 at 07:48:06PM -0800, H. Peter Anvin wrote:
> 
> 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.

Suppose that the root of a iso9660 has entries such as '/', '.' and '..'
all with inode 2 and maybe that there are  some other indications that
the creator applied UNIX style inode numbering, wouldn't it be reasonable
to assume that inode numbers should be trusted?

In which case any wrong inode should be declared a bug in the program
that created the image?

A mount option to handle this could be useful as well.

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

No need to change that part, well, except maybe for knfsd if we cannot
safely export a CD-ROM but that's something I don't know.


It is annoying that wonderful zisofs backups need fixup scripts for the
hard links after a restore.

-- 
Frank