Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!samsung!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.aix
Subject: Re: cpio Out of phase -- get help
Message-ID: <2627@auspex.auspex.com>
Date: 14 Nov 89 00:36:48 GMT
References: <1178@msa3b.UUCP> <2419@servax0.essex.ac.uk>
Reply-To: guy@auspex.auspex.com (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 27

>All cpio "tape" blocks start with a "Magic number", I think this is 0707
>but don't take my word for that.

From the SunOS 4.x "/etc/magic", derived from the S5R3.1 one:

0	short		070707		cpio archive
0	short		0143561		byte-swapped cpio archive
0	string		070707		ASCII cpio archive

I.e. non-"-c" archives start with a 2-byte quantity that has the value
octal 70707 if the archive was written on a machine with the same byte
order and octal 143561 if it was written on a machine with the opposite
byte order (we're talking 2-byte quantities here, there are only two
byte orders for them).  "-c" archives start with 6 bytes containing the
ASCII characters "0", "7", "0", "7", "0", and "7", in order.

>if (3)		-	Read the tape on a machine with the correct byte order.
>			I think the later versions of cpio sort this problem out
>			for you - reading tapes writen on machines with 
>			diffent byte orders even if in non-"c" mode.

The only version I know of that does so is the SunOS one in releases 3.2
and later, and that's only because I stuck in the code to make it do so.
Vanilla versions from AT&T don't do so.  (It ain't that hard; if the
magic number isn't 070707, check whether it's 0143561 and, if so, set a
flag that causes "cpio" to byte-swap only the "cpio" headers - *not* the
file names *nor* the file data.)