gnu@hoptoad.UUCP (John Gilmore) (05/11/87)
From: gnu@hoptoad.UUCP (John Gilmore) I don't know anybody who's ever had trouble reading a tar tape (assuming their hardware could read the medium). I've heard of plenty of troubles with cpio transfers, including the byte swap issues mentioned so well by Guy, but also the fact that there are two formats and one of them is inherently nonportable (and happens to be the default) causes no end of confusion for users just trying to get their data from here to there. All versions of tar are compatible. When researching tar for my implementation, I tracked down various reports of tar tapes that could not be read by other tars, and all turned out to be pilot error. (Laura says she's heard of problems when reading long-filename tapes on short-filename systems, but cpio is no better at this, and I hear that V8 tar has been fixed to rename long-name files while extracting them.) Laura Creighton, sitting next to me, remembers that she had to rewrite cpio several times when trying to read tapes sent from AT&T people to her. On utzoo, a V7 Unix system, there was no cpio, but she had access to versions on other U of T machines. She recalls things like the PWB cpio writing tapes that could not be read by System III, and System III writing tapes that could not be read by some releases of System V, but without a lot of research she can't document these claims. (Anybody else out there run into this more recently?) After looking at the cpio record format typed in by John, it looks like it is a lot more Unix file system specific than tar, e.g. what are inode numbers doing on a portable transfer format? Also, the inode numbers are defined to be unsigned shorts (or 6-digit octal) while in many Unix systems, inode numbers are 32 bits long and will not fit in this format. Of course the binary format should not even be mentioned in the standard, since an "unsigned short" has no portable representation, but it's clear that the octal form is not big enough, so what do we do? Define a new standard "almost like current cpio" but incompatible? Let's stick with tar -- it doesn't expose the innards of the V7 file system, and it works. There is the additional advantage of a public domain implementation of the proposed tar standard (written by me, available from mod.sources), which also served to work out several bugs in the proposal. This implementation has been exchanging data with real source licensed Unix tar's for years now without trouble. It also implements some of the things that cpio can do that Unix tar can't; in particular, reading the list of files to be archived or extracted from standard input. Volume-Number: Volume 11, Number 17
std-unix@ut-sally.UUCP (Moderator, John Quarterman) (05/13/87)
From: decvax!cwruecmp!nitrex!rbl (Rob Lake) In article <8014@ut-sally.UUCP> gnu@hoptoad.UUCP (John Gilmore) writes: >From: gnu@hoptoad.UUCP (John Gilmore) > >I don't know anybody who's ever had trouble reading a tar tape >(assuming their hardware could read the medium). I've had trouble reading tar tapes, given hardware that could read the medium. The problem was with block sizes that were too large for the tape drive/controller/device driver to handle. Never could decide which it was, but --- having once designed a tape controller --- pretty well assumed it was not the drive itself. [ The 3B20 tape controller has this problem. -mod ] Rob Lake decvax!cwruecmp!nitrex!rbl Volume-Number: Volume 11, Number 27