Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site sdcsvax.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!houxm!houxz!vax135!cornell!uw-beaver!tektronix!hplabs!sdcrdcf!sdcsvax!greg From: greg@sdcsvax.UUCP (Greg Noel) Newsgroups: net.unix Subject: Re: tar .vs. cpio Message-ID: <1108@sdcsvax.UUCP> Date: Fri, 10-Aug-84 06:10:26 EDT Article-I.D.: sdcsvax.1108 Posted: Fri Aug 10 06:10:26 1984 Date-Received: Sun, 12-Aug-84 01:37:36 EDT References: <198@ucbopal.CC.Berkeley.ARPA> Organization: NCR Corporation, Torrey Pines Lines: 62 In article <198@ucbopal.CC.Berkeley.ARPA> tut@ucbopal.CC.Berkeley.ARPA writes: >Could someone justify the existence of cpio? What's wrong with tar? Actually, it's easy to justify the existance of cpio. There are at least three reasons: (1) History. They grew up at different organizations. Tar comes from Berkeley and cpio from Bell (now AT&T). (This may not be completely accurate -- I first saw cpio in the PWB release and I first saw tar in a Berkeley system; for all I know, tar may have come with Version 7. The point remains the same, even if the different organizations were within Bell. Tar has changed (grown?) (groan?) at Berkeley (witness the recent complaints about the incompatible tar formats); they picked tar and ran with it, while AT&T went with cpio. I don't justify it, or point fingers at either organization; I just report it.) (2) Problem. They grew up to solve different problems. Tar is a "tape archiver" and its major function is to produce backups of filesystems. (This was in the days when a filesystem would fit on a single tape.) (All right, that's oversimplified.) Its functionality is based upon a program called tp from Version 6 (did tp make it into Version 7?). On the other hand, cpio was designed from the ground up to solve a very different problem -- selectivly copying lists of files (actually, filesystem elements). Thus, it is useful for distributions, or for copying recently-changed files for backup, or for copying a selected part of a directory tree somewhere else, or ..... Tar takes its list of files from the command line, effectivly limiting the number of arguments, while cpio takes them from the standard input, giving no such limitation (this is why tar copies directory trees -- otherwise you couldn't get enough on the tape to make it useful). (I actually consider it a flaw of tar that you MUST copy ALL of a directory tree; there is no way to make the choice of files conditional.) (3) Philosophy. Cpio is more in keeping with the Unix (tm) philosophy, since it seperates the job of SELECTING the files from the job of COPYING the files. ANY algorithm can be used to select the files to be copied, but cpio can still be used to copy them. In fact, I have an application that tries to keep two sets of files in sync on different computers -- it does it by running a shell script that scans a set of files and determines which files have changed since the last run and then passes the names to cpio to be copied. There are about six thousand files to select from; on a given day, anywhere from a hundred to several thousand will be selected for transfer. I don't think tar could do that as well. In case you hadn't noticed, I prefer cpio. There are times when tar is better (if what you really want to do is copy all of a directory, it's just fine, and the interface is simpler), but I find that if it is complicated enough to need to write a shell script then cpio is usually the program of choice. Don't get me wrong -- cpio isn't perfect. Internally, it's a nightmare, and AT&T would be better off to rewrite the whole thing. But it works just fine, and it does what I want it to. BTW, the -c option of cpio does not cause it to write one character at a time; it causes the headers for each file to be in ASCII characters instead of binary. The output is still blocked. Now if the null at the end of the header could be changed into a carriage return, we could use cpio instead of shar format...... (tm) Unix is a footnote of AT&T Bell Laboratories -- -- Greg Noel, NCR Torrey Pines Greg@sdcsvax.UUCP or Greg@nosc.ARPA