In the last episode (Jul 08), Warren Block said: > On Thu, 8 Jul 2010, Anonymous wrote: > > Warren Block <[email protected]> writes: > >> The FreeBSD livefs ISO filesystem hides hard links, so they can't be > >> accurately copied. > > > > Use `tar cf - | tar xf -' to copy them. > > That was my first thought, too. Well, second thought, after 'rsync -aH'. > > But the mounted ISO filesystem doesn't show hard links as hard links: > > # ls -li /mnt/rescue > 416796 -r-xr-xr-x 414 root wheel 4367520 Jun 9 14:49 [ > 399564 -r-xr-xr-x 414 root wheel 4367520 Jun 9 14:49 atacontrol > 399690 -r-xr-xr-x 414 root wheel 4367520 Jun 9 14:49 atmconfig > 399816 -r-xr-xr-x 414 root wheel 4367520 Jun 9 14:49 badsect > ...
It looks like they're halfway hard links :) The link count is 414 for all those files so you know they are hardlinks, but because the inode number is different, there's no way to match up which links correspond to the same file. Each of those files might be unique, just hardlinked to the same names in 413 other identical subdirectories. Unlikely, but possible :) That's probably why tar and rsync can't recreate the links on the destination. I don't think the ISO filesytem format even has the concept of inode numbers, but according to http://lists.freebsd.org/pipermail/freebsd-fs/2006-October/002338.html , mkisofs from the cdrtools port should create hardlinked files with the same starting LBA number, and assuming FreeBSD's cd9660 driver uses that value for its inode number, everything should work. Either the ISOs aren't built with mkisofs, or the driver doesn't use the LBA number for the inode number. -- Dan Nelson [email protected] _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[email protected]"
