Return to BSD News archive
Newsgroups: comp.unix.bsd Path: sserve!manuel!munnari.oz.au!mips!mips!darwin.sura.net!mojo.eng.umd.edu!news!djm From: djm@eng.umd.edu (David J. MacKenzie) Subject: Re: Sorry, everyone, but I'm cpio clueless... Message-ID: <DJM.92Jul20122506@frob.eng.umd.edu> Date: Mon, 20 Jul 92 17:25:06 GMT Organization: Project GLUE, University of Maryland In-Reply-To: terry@npd.Novell.COM's message of Mon, 20 Jul 1992 15:26:50 GMT References: <1992Jul17.160256.4518@news.iastate.edu> <1992Jul17.180345.1296@nrao.edu> <1992Jul18.044401.2343@uvm.edu> <1992Jul20.152650.4070@gateway.novell.com> 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. I think what Garrett was referring to is the default cpio format -- what you get when you don't give cpio the -c option (or -H for SVR4). If you have a cpio archive created that way on a machine with the opposite byte-sex from yours, the UNIX cpio can't read it. GNU cpio and afio can. If you give cpio the -c option (or use the other portable formats the SVR4 cpio supports, and GNU cpio will soon support), then the archive should be the same no matter what your machine's byte-sex. There's no good reason to use the default (binary) cpio format(s) anymore.