This article needs additional citations for verification .(April 2012) |
Original author(s) | Bell Laboratories |
---|---|
Developer(s) | Various open-source and commercial developers |
Initial release | January 1979 |
Stable release(s) | |
Written in | pdtar, star, Plan 9, GNU: C |
Operating system | Unix, Unix-like, Plan 9, Microsoft Windows, IBM i |
Platform | Cross-platform |
Type | Command |
License | BSD tar: BSD-2-Clause GNU tar: GPL-3.0-or-later pdtar: Public domain Plan 9: MIT star: CDDL-1.0 |
Filename extension | .tar |
---|---|
Internet media type | application/x-tar |
Uniform Type Identifier (UTI) | public.tar-archive |
Magic number | u s t a r \0 0 0 at byte offset 257 (for POSIX versions)
Contents |
Latest release | various various |
Type of format | File archiver |
Standard | POSIX since POSIX.1, presently in the definition of pax |
Open format? | Yes |
In computing, tar is a computer software utility for collecting many files into one archive file, often referred to as a tarball, for distribution or backup purposes. The name is derived from "tape archive", as it was originally developed to write data to sequential I/O devices with no file system of their own, such as devices that use magnetic tape. The archive data sets created by tar contain various file system parameters, such as name, timestamps, ownership, file-access permissions, and directory organization. POSIX abandoned tar in favor of pax , yet tar sees continued widespread use.
The command-line utility was first introduced in the Version 7 Unix in January 1979, replacing the tp program (which in turn replaced "tap"). [7] The file structure to store this information was standardized in POSIX.1-1988 [8] and later POSIX.1-2001, [9] and became a format supported by most modern file archiving systems. The tar command was abandoned in POSIX.1-2001 in favor of pax command, which was to support ustar file format; the tar command was indicated for withdrawal in favor of pax command at least since 1994.
Today, Unix-like operating systems usually include tools to support tar files, as well as utilities commonly used to compress them, such as xz, gzip, and bzip2.
The tar command has also been ported to the IBM i operating system. [10]
BSD-tar has been included in Microsoft Windows since Windows 10 April 2018 Update, [11] [12] and there are otherwise multiple third party tools available to read and write these formats on Windows.
Many historic tape drives read and write variable-length data blocks, leaving significant wasted space on the tape between blocks (for the tape to physically start and stop moving). Some tape drives (and raw disks) support only fixed-length data blocks. Also, when writing to any medium such as a file system or network, it takes less time to write one large block than many small blocks. Therefore, the tar command writes data in records of many 512 B blocks. The user can specify a blocking factor, which is the number of blocks per record. The default is 20, producing 10 KiB records. [13]
There are multiple tar file formats, including historical and current ones. Two tar formats are codified in POSIX: ustar and pax. Not codified but still in current use is the GNU tar format.
A tar archive consists of a series of file objects, hence the popular term tarball, referencing how a tarball collects objects of all kinds that stick to its surface. Each file object includes any file data, and is preceded by a 512-byte header record. The file data is written unaltered except that its length is rounded up to a multiple of 512 bytes. The original tar implementation did not care about the contents of the padding bytes, and left the buffer data unaltered, but most modern tar implementations fill the extra space with zeros. [14] The end of an archive is marked by at least two consecutive zero-filled records. (The origin of tar's record size appears to be the 512-byte disk sectors used in the Version 7 Unix file system.) The final block of an archive is padded out to full length with zeros.
The file header record contains metadata about a file. To ensure portability across different architectures with different byte orderings, the information in the header record is encoded in ASCII. Thus if all the files in an archive are ASCII text files, and have ASCII names, then the archive is essentially an ASCII text file (containing many NUL characters).
The fields defined by the original Unix tar format are listed in the table below. The link indicator/file type table includes some modern extensions. When a field is unused it is filled with NUL bytes. The header uses 257 bytes, then is padded with NUL bytes to make it fill a 512 byte record. There is no "magic number" in the header, for file identification.
Pre-POSIX.1-1988 (i.e. v7) tar header:
Field offset | Field size | Field |
---|---|---|
0 | 100 | File name |
100 | 8 | File mode (octal) |
108 | 8 | Owner's numeric user ID (octal) |
116 | 8 | Group's numeric user ID (octal) |
124 | 12 | File size in bytes (octal) |
136 | 12 | Last modification time in numeric Unix time format (octal) |
148 | 8 | Checksum for header record |
156 | 1 | Link indicator (file type) |
157 | 100 | Name of linked file |
The pre-POSIX.1-1988 Link indicator field can have the following values:
Value | Meaning |
---|---|
'0' or (ASCII NUL) | Normal file |
'1' | Hard link |
'2' | Symbolic link |
Some pre-POSIX.1-1988 tar implementations indicated a directory by having a trailing slash (/) in the name.
Numeric values are encoded in octal numbers using ASCII digits, with leading zeroes. For historical reasons, a final NUL or space character should also be used. Thus although there are 12 bytes reserved for storing the file size, only 11 octal digits can be stored. This gives a maximum file size of 8 gigabytes on archived files. To overcome this limitation, in 2001 star introduced a base-256 coding that is indicated by setting the high-order bit of the leftmost byte of a numeric field.[ citation needed ] GNU-tar and BSD-tar followed this idea. Additionally, versions of tar from before the first POSIX standard from 1988 pad the values with spaces instead of zeroes.
The checksum is calculated by taking the sum of the unsigned byte values of the header record with the eight checksum bytes taken to be ASCII spaces (decimal value 32). It is stored as a six digit octal number with leading zeroes followed by a NUL and then a space. Various implementations do not adhere to this format. In addition, some historic tar implementations treated bytes as signed. Implementations typically calculate the checksum both ways, and treat it as good if either the signed or unsigned sum matches the included checksum.
Unix filesystems support multiple links (names) for the same file. If several such files appear in a tar archive, only the first one is archived as a normal file; the rest are archived as hard links, with the "name of linked file" field set to the first one's name. On extraction, such hard links should be recreated in the file system.
Most modern tar programs read and write archives in the UStar (Unix Standard TAR [7] [15] ) format, introduced by the POSIX IEEE P1003.1 standard from 1988. It introduced additional header fields. Older tar programs will ignore the extra information (possibly extracting partially named files), while newer programs will test for the presence of the "ustar" string to determine if the new format is in use. The UStar format allows for longer file names and stores additional information about each file. The maximum filename size is 256, but it is split among a preceding path "filename prefix" and the filename itself, so can be much less. [16]
Field offset | Field size | Field |
---|---|---|
0 | 156 | (Several fields, same as in the old format) |
156 | 1 | Type flag |
157 | 100 | (Same field as in the old format) |
257 | 6 | UStar indicator, "ustar", then NUL |
263 | 2 | UStar version, "00" |
265 | 32 | Owner user name |
297 | 32 | Owner group name |
329 | 8 | Device major number |
337 | 8 | Device minor number |
345 | 155 | Filename prefix |
The type flag field can have the following values:
Value | Meaning |
---|---|
'0' or (ASCII NUL) | Normal file |
'1' | Hard link |
'2' | Symbolic link |
'3' | Character special |
'4' | Block special |
'5' | Directory |
'6' | FIFO |
'7' | Contiguous file |
'g' | Global extended header with meta data (POSIX.1-2001) |
'x' | Extended header with metadata for the next file in the archive (POSIX.1-2001) |
'A'–'Z' | Vendor specific extensions (POSIX.1-1988) |
All other values | Reserved for future standardization |
POSIX.1-1988 vendor specific extensions using link flag values 'A'–'Z' partially have a different meaning with different vendors and thus are seen as outdated and replaced by the POSIX.1-2001 extensions that also include a vendor tag.
Type '7' (Contiguous file) is formally marked as reserved in the POSIX standard, but was meant to indicate files which ought to be contiguously allocated on disk. Few operating systems support creating such files explicitly, and hence most TAR programs do not support them, and will treat type 7 files as if they were type 0 (regular). An exception is older versions of GNU tar, when running on the MASSCOMP RTU (Real Time Unix) operating system, which supported an O_CTG flag to the open() function to request a contiguous file; however, that support was removed from GNU tar version 1.24 onwards.
In 1997, Sun proposed a method for adding extensions to the tar format. This method was later accepted for the POSIX.1-2001 standard. This format is known as extended tar format or pax format. The new tar format allows users to add any type of vendor-tagged vendor-specific enhancements. The following tags are defined by the POSIX standard:
In 2001, the Star program became the first tar to support the new format.[ citation needed ] In 2004, GNU tar supported the new format, [17] though it does not write it as its default output from the tar program yet. [18]
The pax format is designed so that all implementations able to read the UStar format will be able to read the pax format as well. The only exceptions are files that make use of extended features, such as longer file names. For compatibility, these are encoded in the tar files as special x
or g
type files, typically under a PaxHeaders.XXXX
directory. [19] : exthdr.name A pax-supporting implementation would make use of the information, while non-supporting ones like 7-Zip would process them as additional files. [20]
tar [-options] <name of the tar archive> [files or directories which to add into archive]
Basic options:
-c, --create
— create a new archive;-a, --auto-compress
— additionally compress the archive with a compressor which will be automatically determined by the file name extension of the archive. If the archive's name ends with *.tar.gz
then use gzip, if *.tar.xz
then use xz, *.tar.zst
for Zstandard etc.;-r, --append
— append files to the end of an archive;-x, --extract, --get
— extract files from an archive;-f, --file
— specify the archive's name;-t, --list
— show a list of files and folders in the archive;-v, --verbose
— show a list of processed files.Create an archive file archive.tar
from the file README.txt
and directory src
:
$ tar-cvfarchive.tarREADME.txtsrc
Extract contents for the archive.tar
into the current directory:
$ tar-xvfarchive.tar
Create an archive file archive.tar.gz
from the file README.txt
and directory src
and compress it with gzip :
$ tar-cavfarchive.tar.gzREADME.txtsrc
Extract contents for the archive.tar.gz
into the current directory:
$ tar-xvfarchive.tar.gz
A tarpipe is the method of creating an archive on the standard output file of the tar utility and piping it to another tar process on its standard input, working in another directory, where it is unpacked. This process copies an entire source directory tree including all special files, for example:
$ tarcf-srcdir|tarx-Cdestdir
The tar format continues to be used extensively for open-source software distribution. *NIX-distributions use it in various source- and binary-package distribution mechanisms, with most software source code made available in compressed tar archives.[ citation needed ]
The original tar format was created in the early days of Unix, and despite current widespread use, many of its design features are considered dated. [21]
Many older tar implementations do not record nor restore extended attributes (xattrs) or access-control lists (ACLs). In 2001, Star introduced support for ACLs and extended attributes, through its own tags for POSIX.1-2001 pax. bsdtar uses the star extensions to support ACLs. [22] More recent versions of GNU tar support Linux extended attributes, reimplementing star extensions. [23] A number of extensions are reviewed in the filetype manual for BSD tar, tar(5). [22]
Other formats have been created to address the shortcomings of tar.
A tarbomb, in hacker slang, is a tar file that contains many files that extract into the working directory. Such a tar file can create problems by overwriting files of the same name in the working directory, or mixing one project's files into another. It is at best an inconvenience to the user, who is obliged to identify and delete a number of files interspersed with the directory's other contents. Such behavior is considered bad etiquette on the part of the archive's creator.
A related problem is the use of absolute paths or parent directory references when creating tar files. Files extracted from such archives will often be created in unusual locations outside the working directory and, like a tarbomb, have the potential to overwrite existing files. However, modern versions of FreeBSD and GNU tar do not create or extract absolute paths and parent-directory references by default, unless it is explicitly allowed with the flag -P
or the option --absolute-names
. The bsdtar program, which is also available on many operating systems and is the default tar utility on Mac OS X v10.6, also does not follow parent-directory references or symbolic links. [24] [ failed verification ]
If a user has only a very old tar available, which does not feature those security measures, these problems can be mitigated by first examining a tar file using the command tar tf archive.tar
, which lists the contents and allows to exclude problematic files afterwards. These commands do not extract any files, but display the names of all files in the archive. If any are problematic, the user can create a new empty directory and extract the archive into it—or avoid the tar file entirely. Most graphical tools can display the contents of the archive before extracting them. Vim can open tar archives and display their contents. GNU Emacs is also able to open a tar archive and display its contents in a dired buffer.
The tar format was designed without a centralized index or table of content for files and their properties for streaming to tape backup devices. The archive must be read sequentially to list or extract files. For large tar archives, this causes a performance penalty, making tar archives unsuitable for situations that often require random access to individual files.
With a well-formed tar file stored on a seekable (i.e. allows efficient random reads) medium, the tar
program can still relatively quickly (in linear time relative to file count) look for a file by skipping file reads according to the "size" field in the file headers. This is the basis for option -n
in GNU tar. When a tar file is compressed whole, the compression format, being usually non-seekable, prevents this optimization from being done. [25] A number of "indexed" compressors, which are aware of the tar format, can restore this feature for compressed files. [26] To maintain seekability, tar files must be also concatenated properly, by removing the trailing zero block at the end of each file. [27]
Another issue with tar format is that it allows several (possibly different) files in archive to have identical paths and filenames. When extracting such archive, usually the latter version of a file overwrites the former.
This can create a non-explicit (unobvious) tarbomb, which technically does not contain files with absolute paths or referring to parent directories, but still causes overwriting files outside current directory (for example, archive may contain two files with the same path and filename, first of which is a symlink to some location outside current directory, and second of which is a regular file; then extracting such archive on some tar implementations may cause writing to the location pointed to by the symlink).
Historically, many systems have implemented tar, and many general file archivers have at least partial support for tar (often using one of the implementations below). The history of tar is a story of incompatibilities, known as the "tar wars". Most tar implementations can also read and create cpio and pax (the latter actually is a tar-format with POSIX-2001-extensions).
Key implementations in order of origin:
Additionally, most pax and cpio implementations can read and create multiple types of tar files.
tar archive files usually have the file suffix .tar (e.g. somefile.tar).
A tar archive file contains uncompressed byte streams of the files which it contains. To achieve archive compression, a variety of compression programs are available, such as gzip, bzip2, xz, lzip, lzma, zstd, or compress, which compress the entire tar archive. Typically, the compressed form of the archive receives a filename by appending the format-specific compressor suffix to the archive file name. For example, a tar archive archive.tar, is named archive.tar.gz, when it is compressed by gzip.
Popular tar programs like the BSD and GNU versions of tar support the command line options Z (compress), z (gzip), and j (bzip2) to compress or decompress the archive file upon creation or unpacking. Relatively recent additions include --lzma (LZMA), --lzop (lzop), --xz or J (xz), --lzip (lzip), and --zstd. [33] The decompression of these formats is handled automatically if supported filename extensions are used, and compression is handled automatically using the same filename extensions if the option --auto-compress (short form -a) is passed to an applicable version of GNU tar. [16] BSD tar detects an even wider range of compressors (lrzip, lz4), using not the filename but the data within. [34] Unrecognized formats are to be manually compressed or decompressed by piping.
MS-DOS's 8.3 filename limitations resulted in additional conventions for naming compressed tar archives. However, this practice has declined with FAT now offering long filenames.
Compressor | Long | Short |
---|---|---|
bzip2 | .tar.bz2 | .tb2, .tbz, .tbz2, .tz2 |
gzip | .tar.gz | .taz, .tgz |
lzip | .tar.lz | |
lzma | .tar.lzma | .tlz |
lzop | .tar.lzo | |
xz | .tar.xz | .txz |
compress | .tar.Z | .tZ, .taZ |
zstd | .tar.zst | .tzst |
A file archiver is a computer program that combines a number of files together into one archive file, or a series of archive files, for easier transportation or storage. File archivers may employ lossless data compression in their archive formats to reduce the size of the archive.
gzip is a file format and a software application used for file compression and decompression. The program was created by Jean-loup Gailly and Mark Adler as a free software replacement for the compress program used in early Unix systems, and intended for use by GNU. Version 0.1 was first publicly released on 31 October 1992, and version 1.0 followed in February 1993.
The Single UNIX Specification (SUS) is a standard for computer operating systems, compliance with which is required to qualify for using the "UNIX" trademark. The standard specifies programming interfaces for the C language, a command-line shell, and user commands. The core specifications of the SUS known as Base Specifications are developed and maintained by the Austin Group, which is a joint working group of IEEE, ISO/IEC JTC 1/SC 22/WG 15 and The Open Group. If an operating system is submitted to The Open Group for certification, and passes conformance tests, then it is deemed to be compliant with a UNIX standard such as UNIX 98 or UNIX 03.
In computing, ls
is a command to list computer files and directories in Unix and Unix-like operating systems. It is specified by POSIX and the Single UNIX Specification.
ZIP is an archive file format that supports lossless data compression. A ZIP file may contain one or more files or directories that may have been compressed. The ZIP file format permits a number of compression algorithms, though DEFLATE is the most common. This format was originally created in 1989 and was first implemented in PKWARE, Inc.'s PKZIP utility, as a replacement for the previous ARC compression format by Thom Henderson. The ZIP format was then quickly supported by many software utilities other than PKZIP. Microsoft has included built-in ZIP support in versions of Microsoft Windows since 1998 via the "Plus! 98" addon for Windows 98. Native support was added as of the year 2000 in Windows ME. Apple has included built-in ZIP support in Mac OS X 10.3 and later. Most free operating systems have built in support for ZIP in similar manners to Windows and macOS.
compress is a Unix shell compression program based on the LZW compression algorithm. Compared to gzip's fastest setting, compress is slightly slower at compression, slightly faster at decompression, and has a significantly lower compression ratio. 1.8 MiB of memory is used to compress the Hutter Prize data, slightly more than gzip's slowest setting.
7-Zip is a free and open-source file archiver, a utility used to place groups of files within compressed containers known as "archives". It is developed by Igor Pavlov and was first released in 1999. 7-Zip has its own archive format called 7z, but can read and write several others.
7z is a compressed archive file format that supports several different data compression, encryption and pre-processing algorithms. The 7z format initially appeared as implemented by the 7-Zip archiver. The 7-Zip program is publicly available under the terms of the GNU Lesser General Public License. The LZMA SDK 4.62 was placed in the public domain in December 2008. The latest stable version of 7-Zip and LZMA SDK is version 24.05.
deb is the format, as well as filename extension of the software package format for the Debian Linux distribution and its derivatives.
The archiver, also known simply as ar, is a Unix utility that maintains groups of files as a single archive file. Today, ar
is generally used only to create and update static library files that the link editor or linker uses and for generating .deb packages for the Debian family; it can be used to create archives for any purpose, but has been largely replaced by tar
for purposes other than static libraries. An implementation of ar
is included as one of the GNU Binutils.
xargs is a command on Unix and most Unix-like operating systems used to build and execute commands from standard input. It converts input from standard input into arguments to a command.
dd is a command-line utility for Unix, Plan 9, Inferno, and Unix-like operating systems and beyond, the primary purpose of which is to convert and copy files. On Unix, device drivers for hardware and special device files appear in the file system just like normal files; dd can also read and/or write from/to these files, provided that function is implemented in their respective driver. As a result, dd can be used for tasks such as backing up the boot sector of a hard drive, and obtaining a fixed amount of random data. The dd program can also perform conversions on the data as it is copied, including byte order swapping and conversion to and from the ASCII and EBCDIC text encodings.
pax is an archiving utility available for various operating systems and defined since 1995. Rather than sort out the incompatible options that have crept up between tar
and cpio
, along with their implementations across various versions of Unix, the IEEE designed a new archive utility pax that could support various archive formats with useful options from both archivers. The pax
command is available on Unix and Unix-like operating systems and on IBM i, and Microsoft Windows NT until Windows 2000.
mv
is a Unix command that moves one or more files or directories from one place to another. If both filenames are on the same filesystem, this results in a simple file rename; otherwise the file content is copied to the new location and the old file is removed. Using mv
requires the user to have write permission for the directories the file will move between. This is because mv
changes the content of both directories involved in the move. When using the mv
command on files located on the same filesystem, the file's timestamp is not updated.
The file
command is a standard program of Unix and Unix-like operating systems for recognizing the type of data contained in a computer file.
The following tables compare general and technical information for a number of file archivers. Please see the individual products' articles for further information. They are neither all-inclusive nor are some entries necessarily up to date. Unless otherwise specified in the footnotes section, comparisons are based on the stable versions—without add-ons, extensions or external programs.
cpio is a general file archiver utility and its associated file format. It is primarily installed on Unix-like computer operating systems. The software utility was originally intended as a tape archiving program as part of the Programmer's Workbench (PWB/UNIX), and has been a component of virtually every Unix operating system released thereafter. Its name is derived from the phrase copy in and out, in close description of the program's use of standard input and standard output in its operation.
XZ Utils is a set of free software command-line lossless data compressors, including the programs lzma and xz, for Unix-like operating systems and, from version 5.0 onwards, Microsoft Windows. For compression/decompression the Lempel–Ziv–Markov chain algorithm (LZMA) is used. XZ Utils started as a Unix port of Igor Pavlov's LZMA-SDK that has been adapted to fit seamlessly into Unix environments and their usual structure and behavior.
lzip is a free, command-line tool for the compression of data; it employs the Lempel–Ziv–Markov chain algorithm (LZMA) with a user interface that is familiar to users of usual Unix compression tools, such as gzip and bzip2.
cat
is a standard Unix utility that reads files sequentially, writing them to standard output. The name is derived from its function to (con)catenate files . It has been ported to a number of operating systems.
The extended attributes can be very valuable for storing file metadata (e.g. author="John Smith", subject="country landscape"), in the many cases where you do not want or can't store this data in the file internal properties.