livefs hard links

Dan Nelson dnelson at
Thu Jul 8 14:46:36 UTC 2010

In the last episode (Jul 08), Warren Block said:
> On Thu, 8 Jul 2010, Anonymous wrote:
> > Warren Block <wblock at> 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

I don't think the ISO filesytem format even has the concept of inode
numbers, but according to ,
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
	dnelson at

More information about the freebsd-questions mailing list