Xref: utzoo comp.sys.ibm.pc:11599 comp.unix.questions:5498 comp.sys.att:2454
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!amdahl!oliveb!sun!gorodish!guy
From: guy@gorodish.Sun.COM (Guy Harris)
Newsgroups: comp.sys.ibm.pc,comp.unix.questions,comp.sys.att
Subject: Re: tar or cpio?
Message-ID: <41499@sun.uucp>
Date: 10 Feb 88 08:36:43 GMT
References: <246@mancol.UUCP> <1629@cuuxb.ATT.COM> <2506@mibte.UUCP>
Sender: news@sun.uucp
Lines: 40

> > 	5) non-character format cpio archives are not easily moveable to
> > 		machines with different byte ordering.
> 
> The "DD" command will swap bytes. In many cases find, cpio & dd are used.

Unfortunately, "dd" will swap the bytes in every 16-bit quantity written to the
tape (I don't know how any of this works with non-8-bit-"char" machines).  This
is not useful under these circumstances.  Equally unfortunately, the
byte-swapping options of "cpio" will swap only the bytes in the data blocks.
This is also not useful, under almost *any* circumstances.

What you *want* to do is swap only the bytes in the headers, *not* the bytes in
the data blocks and *not* the bytes in the pathnames.  Unfortunately, as the
astute reader will note, the combination of the byte-swapping of "dd" and the
byte-swapping of "cpio" results in the data blocks being unswapped and the
headers being swapped - BUT it also results in the pathnames being swapped!
The net result is precisely what you think is.

The System III "cpio"'s byte-swapping option swapped bytes in the data blocks
*and* in the pathname; combining this with "dd" provided a stupid and
inefficient way of swapping only the bytes in the headers.  The System V
"cpio"s options cannot be combined with "dd" in this fashion to yield something
useful.  (Please do not tell me that this works, or can be made to work.  I
have tried it, when attempting to use the System V "cpio" on a big-endian Sun-3
to read a binary "cpio" tape made with the System V "cpio" on a little-endian
VAX; it does not work, and cannot be made to work without hacking up "cpio".
This is what I eventually did.)

The *correct* thing to do is to make "cpio" detect that the magic number in the
"cpio" header is byte-swapped from its proper value when reading a tape, and
automatically decide to swap the bytes in the headers, and *only* the headers,
as it reads the data.  After trying to read the aformentioned "cpio" tape, I
fixed the 3.2 SunOS "cpio" to do exactly that.

This is, of course, useful only when you have a binary "cpio" archive.
Everybody now should be using "cpio -c" to make "cpio" archives.  They should
also, if using "find" without "cpio" to make "cpio" archives, be using the
"-ncpio" option, which produces ASCII "cpio" headers, rather than the "-cpio"
option.  Unfortunately, the implementor of this option didn't see fit to
document it.