Talk:Cpio
From Wikipedia, the free encyclopedia
curious: how does cpio differ from tar or shar and why might it be preferable? Derex @ 20:55, 8 October 2005 (UTC)
- 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
- more...
- — Keramida 18:19, 10 April 2006 (UTC)
Contents |
[edit] Poorly Biased
I don't know your conventions here but I find this article to be rather offensive. That cpio's use has been replaced by tar is rather laughable. The list citation only mentions the superiority of the tar file format as an interchange format. Cpio is not used as an interchange format but it is certainly used as a common backup format and it does have some operational advantages as opposed to tar where backups are concerned. As stated previously, it supports more formats and it reads from stdin which makes it more flexible and faster when trying to making limited backups. Doing something like:
find . -newer time.tmp -type f | grep -v .core | while read x; do tar -vrf backup.tar $x done
Tends to bog down very quickly when backing up large amounts of data as the data must be moved each time to accommodate the new larger header when the files are appended. Since cpio reads all of the files from stdin at once it only has to create the header once and therefore doesn't have to move any of the data around. I use both utilities and they both have their place; and, I feel that this article should take a more neutral standpoint.
This article should probably also have some reference to afio (http://freshmeat.net/projects/afio/) which is an improved version of cpio that outputs to a far more corruption tolerant format when using compression because it compresses each of the files individually rather then compressing an entire archive.
If you feel differently or if I have done something wrong then you may contact me through my website at http://ilthio.net.
Thank-you Tim Harig
[edit] Duplicated
CPIO is really this article, isn't it? 129.241.158.188 21:34, 12 October 2005 (UTC)
[edit] Merging
Since the name of the program is cpio, the CPIO article should be merged into this one, not the other way around. 83.71.47.204 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)
[edit] c3po disambig.
Probably, it would be a nice idea to make a disambiguation page for C3po :) It really will... --Yuriy
[edit] 8GB Limit
Curious, does cpio still have the 8GB limit? I have made some fairly large archives that I believe exdeeded 8GB.
--S
cpio uses the old binary format by default (for compatibility) which has some limitations including architecture dependence. Whether it as any size limits I do not know; but, GNU cpio supports several formats including newer ASCII based formats. I would suspect that these formats would have arbitrary limits or at least much larger limits then the old binary format. See my website above for contact information if you find out differently.
[edit] Mistake in the article
Commnad "cpio -l" doesn't work 78.60.37.58 (talk) 16:10, 22 November 2007 (UTC)