[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.
I have been trying to come up with a solution to this, and have pretty
much failed. Hopefully the UDF filesystem doesn't have this
problem...
-hpa
-- <hpa@transmeta.com> at work, <hpa@zytor.com> in private! "Unix gives you enough rope to shoot yourself in the foot." Architectures needed: cris ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/