Skip to content

Issues from GNU tar >= 1.24

1 message · Brian Ripley

#
[Moved from R-help with a new subject line.]

R CMD build used with GNU tar >= 1.24 (which is only a couple of 
months old and so not in widespread use) can create tarballs 
containing hard links if the package sources contain (symbolic or 
hard) links.  RGtk2_2.20.4.tar.gz was such a tarball.

I have added support for hard links in R-devel, so such tarballs will 
be unpacked with hard links (or if that fails file copies).

Hard links are supported on POSIX file systems and on NTFS on Windows. 
So this should work fine (and tests correctly) where such file systems 
are in use -- the main exception would be FAT file systems (which 
because of their OS-portability are widely used for external disks and 
USB drives), and those FAT systems tested[*] seem also to work.

The claim about other tars seems false: the other two commonly used 
tars (bsdtar from libarchive used in Mac OS 10.6 and FreeBSD, and AT&T 
Unix tar) deference symbolic links to ordinary files.

So the current position is:

If you have symbolic links in your package sources and use GNU tar >= 
1.24 and use R CMD build to make the package tarball:

- R < 2.11.0 relies on an external tar program
- 2.11.0 <= R <= 2.12.1 may not unpack the tarball correctly on a
   Unix-alike.
- Somewhat accidentally R <= 2.12.1 should unpack it correctly on
   Windows, expanding hard links to file copies.
- R-patched will unpack the tarball correctly, expanding hard links to
   file copies.
- R-devel will unpack the tarball correctly on file systems which
   support hard links, and on the FAT file systems tested.

It seems the best workarounds are

- Do not have links in your package sources (and that advice has been
    added to 'Writing R Extensions')
- If you encounter a tarball which contains links (which can be hard
   to detect: 'tar tvf' does not necessarily list them as such), try
   setting environment variable R_INSTALL_TAR to the path to a 'tar'
   program that handles such links.

[*] Linux, Mac OS X and Windows reported failures on file.link() and 
fell back to file copies.  However, Mac OS X (and not the others) 
seems to support symbolic links on FAT file systems.
On Thu, 6 Jan 2011, Michael Lawrence wrote: