- Many versions of the tar utility, especially on legacy systems, only support a single archive format. The GNU cpio utility (and, typically, other cpio implementations), supports multiple archive formats. One of them, usually referred to as POSIX tar is actually compatible with existing tar utilities, so one can use:
$ find dir/ | cpio -o -H ustar > dir.tar $ tar tvf dir.tar | more
- So, in a sence, cpio provides a superset of the functionality of tar.
- It's worth noting though that many modern tar implementations support a variety of formats too, i.e. the tar(1) utility of recent FreeBSD versions, so this distinction has started to blur and/or fade away a bit.
- Other important differences include:
- cpio uses stdin to read the list of files to archive, making it easy to exclude certain patterns of files by grepping them out, making concatenation of file lists easy, etc.
- cpio has a pass-through mode, which wasn't available in early tar versions
- — Keramida 18:19, 10 April 2006 (UTC)
Since the name of the program is cpio, the CPIO article should be merged into this one, not the other way around. 18.104.22.168 22:39, 23 January 2006 (UTC)
- Sure thing. I made the mess, I'll clean it up. I've got a few things to sort out so I'll check back in 24 hours and merge the articles if no one has any objections.
- Another point to note is that the name of the archiving application is "Cpio" whereas it's only the extension of an archive that is lowercase (Even then it might not always be the case.) I'm unsure if a lowercase title is really necessary in this article after merging. The CPIO article refers mostly to the application which starts with a capital, so after the merge, the case "Cpio" is more valid. :-)
- Techtoucian 11:00, 25 January 2006 (UTC)
Probably, it would be a nice idea to make a disambiguation page for C3po :) It really will... --Yuriy
Curious, does cpio still have the 8GB limit? I have made some fairly large archives that I believe exdeeded 8GB.
cpio uses the old binary format by default (for compatibility) which has some limitations including architecture dependence. Several versions of cpio support newer formats which are portable between architectures and have higher limits.  and personal experience suggests that limits of the original cpio are pretty limited.
In its place, I suggest the use of afio (http://freshmeat.net/projects/afio/), an improved version of cpio.
afio versions 2.4.8 and above have their own file format (referenced in the man page as "Large ASCII" which has much higher if not arbitrary limits. I have used it against archives of overall size within hundreds of gigabytes, containing over 750,000 files some exceeding 4 gigabytes in size.
afio uses the old cpio format be default if possible for compatibility; but, it will revert to the more capable format if (from the afio man page):
- A file has a size of larger the 2GB
- The archive contains more than 64K files which ahve hard links
- A file, directory, or special file has a UID or GID value larger than 65535
Plus, afio compresses or encrypts single files so small corruptions are not likely to prevent restoration of more then a single file. Note that both cpio and afio were designed as backup utilities rather then archive utilities such as tar. Their file format was never designed as an interchange format.
Tim Harig (http://ilthio.net)
Mistake in the article
- The equivalent of 'tar xf' is 'cpio -i -d -m' (BSD cpio) or 'cpio -i --make-directories --preserve-modification-time --no-absolute-filenames' (GNU cpio).
- Professor Tournesol (talk) 02:36, 21 January 2010 (UTC)
Self inclusion problem
% find . -depth -print | cpio -ov > tree.cpio
Seems to me that cpio is going to include the destination file (at least part of it) in itself with this command. —Preceding unsigned comment added by P4p4 n0eL (talk • contribs) 01:50, 11 May 2010 (UTC)