1

There are many archival tools for Unix, with varying degrees of availability. To make matters more confusing, many of them can write each other's formats.

I am seeking more information on their relative merits, and why I would want one over another (in differing circumstances).

The landscape of archivers, as I understand it (only considering F/LOSS software):

Tar family archivers

CPIO family archivers

Pax

  • The MirBSD PAX included w/ Linux distros

Dump/Restore

  • dump included with your OS/distro

Other Archivers

  • 7zip
  • zip
  • dar

The Question

I am aware of this comparison, showing that dump beats (old) tar and cpio for dealing with various anomalies in the file system and exactly replicating its contents. However, dump is mostly oriented towards file-system-level archiving and doesn't get great support on Linux (at least Linus isn't very interested in keeping it running).

In general, why would I choose one of these archivers, particularly tar/cpio/pax, over another, and why? Which one should I generally reach for first?

Michael Ekstrand
  • 2,064
  • 3
  • 21
  • 23
  • This question is too broad. A short look at the article which you have linked makes clear that a "complete" answer does not fit the Q&A format of this site. – Hauke Laging May 17 '13 at 22:05
  • Just a quick note: star can be seen as a portable and filesystem independent replacement for the `ufdump` utility. Star supports incremental backups and restores and uses the same basic algorithm as `ufsdump / ufsrestore`. Star is even typically 30% faster than the historical dump/restore implementation. – schily Sep 10 '15 at 14:39

1 Answers1

1

cpio is a standard format, each of the others (except possibly for pax) has quirks. Second best (because it is very portable) is GNU tar.

don_crissti
  • 79,330
  • 30
  • 216
  • 245
vonbrand
  • 18,156
  • 2
  • 37
  • 59
  • The cpio archive format is very limited and was abandoned by POSIX because it is not extendable. – schily Sep 10 '15 at 14:40
  • 1
    @schily - cpio was not abandoned by POSIX - the `pax` utility is required to read/write cpio archives, though it defaults to writing USTAR type archives - the same way GNU `tar` does. i disagree with this answer that either cpio or GNU `tar` should be preferred to `pax` - which can *(more or less)* handle both formats, but can also portably extend the USTAR archive format to the pax archive format *(also handled by GNU `tar`)* and so deal with very long filenames and much else. – mikeserv Oct 24 '15 at 11:41
  • @mikeserv You are confusing archive formats with archival programs in your comment. Both `tar` and `cpio` have been in the first POSIX version. The cpio progam however was added late on request by AT&T because AT&T told their customers that cpio is the upcoming new standard. This happened around 1990 and is widely known as **the tarwars**. Both `cpio` and `tar` at that time suffered from deficits in the command line interface. As a result of the tar wars, the program `pax` was defined and standardized and added to SUSv2 (1997). Cpio and tar have been removed with SUSv3 (2001). – schily Oct 26 '15 at 11:21
  • Cont: Unfortunately, `pax` is more or less a mixture of the CLIs from `cpio` and `tar` and suffers from both CLI problems. This may be why enhanced tar implementations like `star` (1982) and `gtar` (1989) are more popular than `pax`. – schily Oct 26 '15 at 11:23
  • Cont. What I was talking about is the cpio archive format that suffers from the problem that is rather is **five** incompatible formats. Every time, you like to enhance the cpio archive format, you need to create a completely new archive variant that cannot be read by previous archivers. This is why the cpio archive format was declared deprecated by POSIX after Sun (in 1997) made a proposal on how to create an enhanceable format based on the tar archive format. The new format is part of an approved POSIX version since the SUSv3 went stable in december 2001. – schily Oct 26 '15 at 11:29
  • Cont. The cpio format has many problems. It e.g. cannot handle hard links decently because the inode numbers are limited to 16 bits and it cannot handle large files. The only limitation in the eXtended tar format is that the sum of all meta data for a single file cannot exceed 8 GB. – schily Oct 26 '15 at 11:35
  • Cont: As a result, `star` introduced many extensions that allow to add more meta data (e.g. ACLs, hints on renamed files, ...) that turned star into a filesystem type independend incremental backup program with the same basic concept as `ufsdump` from BSD. Ufsdump is limited top UFS. Many other tar implementations, such as `gtar` and `libarchive` reimplemented the archive format enhancements from `star,` but do not support true incemental dump/restore. – schily Oct 26 '15 at 11:38
  • @schily - too many Cont., but i lump the archive/archivers together. star is not very popular as far as i know, though, and definitely i, at least, can use the pax cli w/ ease. – mikeserv Oct 26 '15 at 15:28
  • As far as I can tell, star is very popular amongst sysadmins. It may be that some Linux distros do not understand what they miss when they do not create star packages. Look at e.g. RedHat, they seem to prefer a self made and broken ACL patch in gtar instead of just providing a working star. – schily Oct 26 '15 at 16:12