Create a Tar Archive
Create a tar archive.
tar(tarfile, files = NULL, compression = c("none", "gzip", "bzip2", "xz"), compression_level = 6, tar = Sys.getenv("tar"), extra_flags = "")
- The pathname of the tar file: tilde expansion (see
path.expand) will be performed. Alternatively, a connection that can be used for binary writes.
- A character vector of filepaths to be archived: the default is to archive all files under the current directory.
- character string giving the type of compression to be used (default none). Can be abbreviated.
- integer: the level of compression. Only used for the internal method.
- character string: the path to the command to be used. If
the command itself contains spaces it needs to be quoted (e.g., by
shQuote) -- but argument
tarcan also contain flags separated from the command by spaces.
- any extra flags for an external
This is either a wrapper for a
tar command or uses an
internal implementation in R. The latter is used if
is a connection or if the argument
"" (the factory-fresh default). Note that whereas
Unix-alike versions of R set the environment variable TAR, its
value is not the default for this function.
extra_flags is passed to an external
so is platform-dependent. Possibly useful values include -h
(follow symbolic links, also -L on some platforms),
--acls, --exclude-backups, --exclude-vcs (and
similar) and on Windows --force-local (so drives can be
included in filepaths: however, this is the default for the
tar). For GNU
--format=ustar forces a more portable format. (The default is
set at compilation and will be shown at the end of the output from
tar --help: for version 1.28 out-of-the-box it is
--format=gnu, but the manual says the intention is to change
to --format=pax which GNU incorrectly calls POSIX --
it was never part of the POSIX standard for
tar and should
not be used.)
bsdtar, --format=ustar is more
portable than the default.
The return code from
0for the internal version, invisibly.
The tar format no longer has an agreed standard!
Unix Standard Tar was part of POSIX 1003.1:1998 but has been
removed in favour of
pax, and in any case many common
implementations diverged from the former standard. Many R platforms
use a version of GNU
Windows), but the behaviour seems to be changed with each version. OS
X >= 10.6 and FreeBSD use
bsdttar from the
libarchive project, and commercial Unixes will have their own
versions. Known problems arise from
- The handling of file paths of more than 100 bytes. These were
unsupported in early versions of
tar, and supported in one way by POSIX
tarand in another by GNU
tarand yet another by the POSIX
paxcommand which recent
tarprograms often support. The internal implementation warns on paths of more than 100 bytes, uses the ustar way from the 1998 POSIX standard which supports up to 256 bytes (depending on the path: in particular the final component is limited to 100 bytes) if possible, otherwise the GNU way (which is widely supported, including by
untar). Most formats do not record the encoding of file paths.
- (File) links.
tarwas developed on an OS that used hard links, and physical files that were referred to more than once in the list of files to be included were included only once, the remaining instances being added as links. Later a means to include symbolic links was added. The internal implementation supports symbolic links (on OSes that support them), only. Of course, the question arises as to how links should be unpacked on OSes that do not support them: for regular files file copies can be used. Names of links in the ustar format are restricted to 100 bytes. There is an GNU extension for arbitrarily long link names, but
bsdtarignores it. The internal method uses the GNU extension, with a warning.
- Header fields, in particular the padding to be used when fields are not full or not used. POSIX did define the correct behaviour but commonly used implementations did (and still do) not comply.
- File sizes. The ustar format is restricted to 8GB per (uncompressed) file.
tarwhich by default pads with nul to a multiple of 20 blocks (10KB). Implementations which pad differ on whether the block padding should occur before or after compression (or both): padding was designed for improved performance on physical tape drives.
for the way the POSIX utility