🚀 go-pugleaf

> Recently I attempted to read the /usr tape from the System V Release 2.0
> distribution for VAX processors.  It comes from AT&T in cpio(1)
> format, and Sun distributes a version of cpio from SysV.2 with OS 3.0.
> I found an interesting problem:
> 	If one tried to read the tape directly, lo and behold it was byteswapped
> so cpio complained.  Fair enough.  In the manual page for cpio, it
> explicitly warns of byteswapped cpio tapes, and also warns that the `-s'
> option will not help because it only swaps data bytes, and not those in the
> header.  The cure, as prescribed, is to dd(1) the contents first with the
> `conv=swab' option to swap all the bytes, including the header, before
> feeding to cpio (with the `-s' option set)....
...
> % dd if=/dev/rmt0 ibs=10b conv=swab | cpio -istvBm | head -15
> 40775  sys         0  Oct 15 18:55:51 1983  
> 40775  uucp        0  Nov  4 12:32:17 1983  da
...
> How this might have arisen???  Is it a bug in the way
> it (the tape) was written originally, or a bug in cpio(1)?
> Or in the way a VAX writes char arrays?

There are two kinds of byte swapping you might encounter: swapping
caused by ill-conceived tape controllers and swapping of binary fields
in cpio headers.  You are trying to correct for the first, but you are
being bitten by the second.  Based on your cpio command, the tape was
written without the "c" option, which means the headers are written in
machine-dependent binary instead of ascii.  Character fields are in
normal order, however.  The dd byte-swap trick is swapping the
correctly-written ascii data, which includes the file name.

As to why the tape wasn't written with -ocB: ask AT&T!  My guess is
that the policy is to write a tape that is compatible with the machine
it is licensed to be read on.
-- 

Griff Smith	AT&T (Bell Laboratories), Murray Hill
Phone:		(201) 582-7736
UUCP:		{allegra|ihnp4}!ulysses!ggs
Internet:	ggs@ulysses.uucp