cpio(1) under Sun 3.0; or, does System V write filenames backwards?

[Greg Earle]

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).  As I was only interested in
a table of contents, I merely tried to get one via the `-t' and `-v' options
to produce an `ls -l'-like output.  In doing so, I discovered that swapping
all the bytes made cpio happy, yet somehow the filenames were still coming 
out byteswapped!!  Example:

% 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
40775  uucp        0  Apr 26 07:35:16 1982  da/mcatc
40775  uucp        0  Jan 28 11:19:44 1982  da/mcatcn/ti
40775  uucp        0  Jan 28 11:19:44 1982  da/mcatcf/siac
40775  uucp        0  Jan 28 11:19:44 1982  da/mcatcs/mua
100600 root        0  Dec 31 21:00:00 1969  da/musol
100664 sys         0  Jun 10 07:05:33 1982  da/mrefrli
100664 uucp        0  Dec 31 21:00:00 1969  da/mapcc
40775  uucp        0  Jun 10 09:21:13 1980  da/masc
40775  sys         0  Nov  7 07:50:23 1983  ib
100775 sys     10148  Nov  5 19:16:31 1983  ib/ncpta
100775 sys     10760  Nov  5 17:14:27 1983  ib/napkc
100775 sys     10148  Nov  5 19:16:31 1983  ib/nnuapkc
100775 sys       964  Nov  5 19:32:05 1983  ib/nuuotk

I assumed that byteswapping everything would take care of the filenames
as well, but apparently they are in the `correct' order (for Suns &
680x0 architecture, at any rate) before the byteswap.

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?

I have implemented a `fix', based on this source version:
>#ifndef lint
>static	char sccsid[] = "@(#)cpio.c 1.1 86/02/03 SMI"; /* from S5R2 1.17 */
>#endif

--------------
diff -l -cb /usr/src/sun/usr.bin/cpio.c /tmp/cpio.c
*** /usr/src/sun/usr.bin/cpio.c	Mon Feb  3 23:58:42 1986
--- /tmp/cpio.c	Wed Sep  3 20:10:23 1986
***************
*** 602,609
  	}
  	if(Cflag)
  		readhdr(Hdr.h_name, Hdr.h_namesize);
! 	else
! 		bread(Hdr.h_name, Hdr.h_namesize);
  	if(EQ(Hdr.h_name, "TRAILER!!!"))
  		return 0;
  	ftype = Hdr.h_mode & Filetype;

--- 602,611 -----
  	}
  	if(Cflag)
  		readhdr(Hdr.h_name, Hdr.h_namesize);
! 	else {
! 		bread(Name, Hdr.h_namesize);
! 		swab(Name, Hdr.h_name, (Hdr.h_namesize + 1) & ~001);
! 	}
  	if(EQ(Hdr.h_name, "TRAILER!!!"))
  		return 0;
  	ftype = Hdr.h_mode & Filetype;
--------------

The results of this fix:
% dd if=/dev/rmt0 ibs=10b conv=swab | cpio.fixed -istvBm | head -16
40775  sys         0  Oct 15 18:55:51 1983  .
40775  uucp        0  Nov  4 12:32:17 1983  adm
40775  uucp        0  Apr 26 07:35:16 1982  adm/acct
40775  uucp        0  Jan 28 11:19:44 1982  adm/acct/nite
40775  uucp        0  Jan 28 11:19:44 1982  adm/acct/fiscal
40775  uucp        0  Jan 28 11:19:44 1982  adm/acct/sum
100600 root        0  Dec 31 21:00:00 1969  adm/sulog
100664 sys         0  Jun 10 07:05:33 1982  adm/errfile
100664 uucp        0  Dec 31 21:00:00 1969  adm/pacct
40775  uucp        0  Jun 10 09:21:13 1980  adm/sa
40775  sys         0  Nov  7 07:50:23 1983  bin
100775 sys     10148  Nov  5 19:16:31 1983  bin/pcat
100775 sys     10760  Nov  5 17:14:27 1983  bin/pack
100775 sys     10148  Nov  5 19:16:31 1983  bin/unpack
100775 sys       964  Nov  5 19:32:05 1983  bin/uuto
100775 sys       357  Nov  5 17:32:42 1983  bin/scc

This looks a little more reasonable; but I don't know if it is a `fix' or
a `kludge to counteract a certain non-uniform condition'.

Any clarification would be appreciated.

-- 
	Greg Earle		UUCP: sdcrdcf!smeagol!earle; attmail!earle
	JPL			ARPA: elroy!smeagol!earle at csvax.caltech.edu
				AT&T: +1 818 354 0876

I'm continually AMAZED at th'breathtaking effects of WIND EROSION!!