Re: Why do Informix Products ship with TAR and not CPIO?

In article <5m05dv$7lq@cssun.mathcs.emory.edu>, Jonathan Leffler <johnl@informix.com> writes >>Date: Tue, 20 May 1997 23:44:40 -0600 >>From: Tim <thood29@idt.net> >>X-Informix-List-Id: <list.14591> >> >>Greg McGregor wrote: >>>Why does Informix TAR instead of CPIO? Are there any benefits from one to the >other? >> >>Actually, of the Informix products I have installed in the past >>(including from floppies), I have received both tar and cpio formatted >>media. > >The choice depends primarily on which platform you are on, and secondarily >on the version of the Informix software you are using. You're more likely >to encounter cpio on recent software. > >>Indeed, more often than not (for the products I purchased/installed), I >>received the product in cpio format. I imagine their choice is based more >>on the platform/OS than any specific bias for/against tar or cpio. > >These days, the biggest factor is whether you can list all the files for >the product on the command line or not. > >As someone else noted, tar is easier to use if you simply want to copy >everything underneath some directory to tape. However, the way the Unix >distribution phase works means that all the files for a number of products >are copied to a work area, and then different subsets of these files are >copied onto the tape image. To achieve that with tar, you have to list the >files (but not the directories) one by one on the command line. Until the Or use the F option to tar and have a file containing filenames one per line. ( Use tar cvfF <device> <file containing filelist>). Only newer version of tar support the F option. >advent of GLS, you could usually get away with doing that. With the advent >of GLS, the file lists have grown humongously long and it is no longer very >sensible to try it -- it certainly isn't as portable as cpio with the -c >option. By contrast, cpio reads its file list from its standard input, so >it does not run into problems with the size of the argument list. So, >nowadays, you will generally find that the software is released with cpio >archives. > >As the same 'someone else' noted, it is important to use the -c option with >cpio. In fact, I never use cpio without it. That allows my tapes to be >read on pretty much any other machine. > I have had problems where cpio -c -B tapes could not be read on another machine. >However, tape blocking is another issue. With 0.5 inch drives, it was >critical to get the blocking factor specified correctly. The slowest >operation I did with a tape was reading a half-inch tape. I'd written it >with cpio (and no dd) on a machine with a clever controller that managed to >hide the fact that the block size was 0.5 kB. Unfortunately, the machine I >had to read it on didn't have the clever controller so the tape sat there >for an hour or so, reading a 0.5 kB block, then stopping, swinging back and >reading the next block. It was rather like watching a pendulum. The tape >did rotate overall, but it was very slow (10 seconds per revolution). Only >the fact that the machine with the clever controller was on the other side >of Paris and it was rush hour stopped us from rewriting the tape. That is >a mistake you make once. > Ouch! >FWIW: tar defaults to a block size of 20 * 0.5 kB; cpio defaults to 1 * 0.5 >kB unless you specify -B when it changes to 10 * 0.5 kB. I usually use dd >to write to the tape in bigger chunks: > >cat filelist | cpio -ocvB | dd of=/dev/rmt/0 ibs=5k obs=64k > >With most cartridge tape drives, the blocking factor is not critical; pace >the AIX crew for whom it can be a problem resolved by fiddling with the >drive parameters via smit. On Xenix, tar used to default to a 1 * 0.5 kB Yes, we do that will an AIX box and smit - real pain. >block size, and then complain when it was writing to a floppy drive; you >had to specify an even block size. I don't recall whether this afflicted >SCO Unix or not, but I guess its been fixed. Otherwise, when writing to I never on the latest version of Xenis and SCO Unix. >disk, block size is barely an issue. I use the B option, but I've never >measured the difference. > >For all my own work when I'm not constrained by someone else, I use cpio. >I've never had portability problems unless someone forgot to use the '-c' >option. > I have mind you I have cases where a) tar works and cpio doesn't (even with -c -C65536 option) b) cpio works and tar doesn't ??? c) Tar on machine A to tape and tape CAN be read on Machine B Tar on machine B to tape and tape CANNOT be read on Mahine B (stops precisely at 5Mb boundary with corruption message). Now if I could just find something that always worked. >Yours, >Jonathan Leffler (johnl@informix.com) #include <disclaimer.h> -- David Williams