Return to BSD News archive
Newsgroups: comp.unix.bsd Path: sserve!manuel!munnari.oz.au!mips!mips!newsun!gateway.novell.com!terry From: terry@npd.Novell.COM (Terry Lambert) Subject: Re: Sorry, everyone, but I'm cpio clueless... Message-ID: <1992Jul20.152650.4070@gateway.novell.com> Sender: news@gateway.novell.com (NetNews) Nntp-Posting-Host: thisbe.eng.sandy.novell.com Organization: Novell NPD -- Sandy, UT References: <1992Jul17.160256.4518@news.iastate.edu> <1992Jul17.180345.1296@nrao.edu> <1992Jul18.044401.2343@uvm.edu> Date: Mon, 20 Jul 1992 15:26:50 GMT In article <1992Jul18.044401.2343@uvm.edu> wollman@sadye (Garrett Wollman) writes: > - The only cpio program that tries to make up for byte-sex problems >is GNU cpio. Being a tar fan, and hoping for the quick death of cpio, can't stop me from correcting you here. Whether or not there is a dependancy is based on the options you use. If you use "oacumvB", then there is not a byte order problem. Certainly, you can make the argument that various QIC-11 and QIC-20, as well as 150M format tape drives are byte-order dependant, but this is true of tar as well, as it is more a property of the tape driver/firmware. This can generally be overcome with a "dd if=<dev> conv=swab of=<image>" on input. One can substitute a pipe to cpio for the "of=<image>" part of the command. The only other real problem is tape drivers in machines like the NCR Tower 32 and Tower XP boxes, which insist on reading full records. If on writing the tape you use a pipe to "dd conv=sync" rather than going straight to the device, you alleviate this problem as well. Regards, Terry Lambert terry_lambert@gateway.novell.com terry@icarus.weber.edu --- Disclaimer: Any opinions in this posting are my own and not those of my present or previous employers.