restoring hard linked files from zisofs/iso9660 w. RR

restoring hard linked files from zisofs/iso9660 w. RR

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

-- 
Frank

Re: restoring hard linked files from zisofs/iso9660 w. RR

[Peter Wächtler]

Frank van Maarseveen schrieb:
> 
> 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.

Re: restoring hard linked files from zisofs/iso9660 w. RR

[H. Peter Anvin]

Followup to:  <20020125135545.A28897@espoo.tasking.nl>
By author:    Frank van Maarseveen <fvm@altium.nl>
In newsgroup: linux.dev.kernel
>
> 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?

> 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
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: restoring hard linked files from zisofs/iso9660 w. RR

[Frank van Maarseveen]

On Fri, Jan 25, 2002 at 09:55:57AM -0800, H. Peter Anvin wrote:
> 
> 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.

-- 
Frank

Re: restoring hard linked files from zisofs/iso9660 w. RR

[H. Peter Anvin]

Frank van Maarseveen wrote:

> On Fri, Jan 25, 2002 at 09:55:57AM -0800, H. Peter Anvin wrote:
> 
>>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


 

Re: restoring hard linked files from zisofs/iso9660 w. RR

[H. Peter Anvin]

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