restoring hard linked files from zisofs/iso9660 w. RR
This doesn't seem to work due to inode number differences. Is this a fundamental problem or can it be solved somehow, e.g. by an attribute which refers to a sort of "original" inode number?
or by a more advanced inode number synthesis in fs/isofs?
Signature · 1 line
Frank
Quoted 8 lines · Frank van Maarseveen
This doesn't seem to work due to inode number differences. Is this a fundamental problem or can it be solved somehow, e.g. by an attribute which refers to a sort of "original" inode number?
or by a more advanced inode number synthesis in fs/isofs?
Don't know about isofs, but hardlinks do not use an inode. It's just another entry in a directory pointing to a "used" inode (there is another entry refering to the same inode)
fast symlinks do occupy an inode, symlinks an inode + 1 diskblock.
Followup to: <[email protected]> By author: Frank van Maarseveen <[email protected]> In newsgroup: linux.dev.kernel
Quoted 6 lines
This doesn't seem to work due to inode number differences. Is this a fundamental problem or can it be solved somehow, e.g. by an attribute which refers to a sort of "original" inode number?
WHAT doesn't work?
Quoted 1 line
or by a more advanced inode number synthesis in fs/isofs?
There is, I belive, an inode number RR attribute. Last I checked I was happily using hard links with RockRidge...
-hpa
Signature · 3 lines
<[email protected]> at work, <[email protected]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
Quoted 4 lines · H. Peter Anvin
WHAT doesn't work?
There is, I belive, an inode number RR attribute. Last I checked I was happily using hard links with RockRidge...
Try restoring a few hard linked files from such a CD. The links will break because the inodes of hard linked objects on CD do not have an identical inode number anymore.
Signature · 1 line
Frank
Quoted 10 lines · Frank van Maarseveen
Quoted 3 lines · H. Peter Anvin
WHAT doesn't work?
There is, I belive, an inode number RR attribute. Last I checked I was happily using hard links with RockRidge...Try restoring a few hard linked files from such a CD. The links will break because the inodes of hard linked objects on CD do not have an identical inode number anymore.
What do you mean with "restore" in this context... (dump/restore clearly don't apply.)
Please give a "I used the following mkisofs options to make the CD and then I see the following when I execute this command after mounting the CD image with the following mount options..."
-hpa
Okay... I have successfully reproduced this bug. It's definitely a Linux kernel bug -- mkisofs correctly puts file numbers (inode numbers) in the PX Rock Ridge entries.
Unfortunately it is a pretty deep decision in the Linux isofs that the inode number is the offset of the directory entry; isofs pretty much needs to be rewritten to be dentry-centric rather than inode-centric on order to resolve this. Note that dentry-centric operation is the sane thing for something like isofs, so this wouldn't be a bad idea.
Unfortunately, that doesn't solve all problems: there is no structure to the inode numbers provided in the PX entries, and there is the potential for collision when used on a disc which is only partially RockRidge (which is legal.) This has to be taken into account, and all of these things have to be done without reading the whole disc first...
-hpa