Tar – Unpacking Tarball with Hard Links on File System Without Hard Links

afshard linktar

I got a tarball (let's say t.tar.gz) that contains the following files

./a/a.txt
./b/b.txt

where ./b/b.txt is a hard link to ./a/a.txt.

I want to unpack the tarball on a network file system (AFS) that only supports hard links in the same directory (see here).
Therefore, just unpacking it via tar -xzf t.tar.gz raises an error that the hard link ./b/b.txt cannot be created.

So far, my solution to the problem was to unpack ./t.tar.gz on a file system that supports ordinary hard links. Then pack it again with the option --hard-dereference as the GNU tar manual proposes. And lastly, unpack that new tarball into the AFS.

As this is unsatisfactory for me, I'm asking if there is an easier way to get the content of the archive unpacked directly to it's final destination? Such as an equivalent option to --hard-dereference for unpacking instead of archiving?

Best Answer

Mount the archive as a directory, for example with AVFS, then use your favorite file copying tool.

mountavfs
cp -a --no-preserve=links ~/.avfs/path/to/t.tar.gz\# target-directory/

mountavfs
rsync -a ~/.avfs/path/to/t.tar.gz\#/ target-directory/

Related Solutions

Hard Links – How to Dereference Hard Links

By default, if you tell tar to archive a file with hard links, and more than one such link is included among the files to be archived, it archives the file only once, and records the second (and any additional names) as hard links. This means that when you extract that archive, the hard links will be restored.

If you use the --hard-dereference option, then tar does not preserve hard links. Instead, it treats them as independent files that just happen to have the same contents and metadata. When you extract the archive, the files will be independent.

Note: It recognizes hard links by first checking the link count of the file. It records the device number and inode of each file with more than one link, and uses that to detect when the same file is being archived again. (When you use --hard-dereference, it does not do this.)

Dpkg replacing files on a FAT filesystem

The behaviour you're seeing is implemented in archives.c in the dpkg source, line 1030 (for version 1.18.1):

debug(dbg_eachfiledetail, "tarobject nondirectory, 'link' backup");
if (link(fnamevb.buf,fnametmpvb.buf))
  ohshite(_("unable to make backup link of '%.255s' before installing new version"),
          ti->name);

It seems to me that you could handle the link failure by falling back to the rename behaviour used lines 1003 and following; something like (this is untested):

debug(dbg_eachfiledetail, "tarobject nondirectory, 'link' backup");
if (link(fnamevb.buf,fnametmpvb.buf)) {
  debug(dbg_eachfiledetail,"link failed, nonatomic");
  nifd->namenode->flags |= fnnf_no_atomic_overwrite;
  if (rename(fnamevb.buf,fnametmpvb.buf))
    ohshite(_("unable to move aside '%.255s' to install new version"),
            ti->name);
}

I'm not a dpkg expert though... (And there's no option already available in dpkg to provide this behaviour.)

Best Answer

Related Solutions

Hard Links – How to Dereference Hard Links

Dpkg replacing files on a FAT filesystem

Related Question