Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!ll-xn!cit-vax!elroy!smeagol!earle From: earle@smeagol.UUCP (Greg Earle) Newsgroups: net.bugs.4bsd,net.unix-wizards Subject: cpio(1) under Sun 3.0; or, does System V write filenames backwards? Message-ID: <760@smeagol.UUCP> Date: Wed, 3-Sep-86 23:56:18 EDT Article-I.D.: smeagol.760 Posted: Wed Sep 3 23:56:18 1986 Date-Received: Thu, 4-Sep-86 21:31:52 EDT Organization: JPL, Pasadena CA Lines: 104 Keywords: cpio byteswap header Xref: mnetor net.bugs.4bsd:910 net.unix-wizards:7773 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@csvax.caltech.edu AT&T: +1 818 354 0876 I'm continually AMAZED at th'breathtaking effects of WIND EROSION!!