Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 8/7/84; site rlgvax.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!ihnp4!zehntel!hplabs!hao!seismo!rlgvax!guy From: guy@rlgvax.UUCP (Guy Harris) Newsgroups: net.unix Subject: Re: (tar .vs. cpio) : a question Message-ID: <59@rlgvax.UUCP> Date: Thu, 16-Aug-84 21:11:17 EDT Article-I.D.: rlgvax.59 Posted: Thu Aug 16 21:11:17 1984 Date-Received: Sun, 19-Aug-84 01:34:01 EDT References: <12499@sri-arpa.UUCP> Organization: CCI Office Systems Group, Reston, VA Lines: 48 "cpio"s support for multi-volume tapes involves "switching volumes" whenever a read or write returns an error or returns fewer bytes than were asked to be read/written. If the output is a character special file, it asks you to give the name of a new volume (which would be the same or another tape drive) and retries the read/write when the user enters it. If it's not a character special file, it just reports the error and exits. Making archiving programs like "tar" or "cpio" check whether something is a magtape and do special things on a magtape impairs file flexibility not one whit, any more than a program written to use "termcap" making use of insert line/delete line characteristics when they exist impairs that program's ability to use arbitrary terminals, as long as the programs in question do something correct on non-magtapes/terminals without IL/DL. If you don't make use of the EOT indication that magtape drives give you for free, you end up with an abortion like the various UNIX dump/restore programs' "dead reckoning" method for finding the end of tape (which sucks because 1) due to write errors being handled with an extended interrecord gap, the calculation may be wrong and 2) if you put several incremental dumps on one tape, only the first dump can deal with running out of tape unless you glop up "dump" by having it output a "tape length used so far" and accept that length as an argument. The only real problem is that 1) not all UNIX systems handle magtapes well; the Berkeley mag tape "ioctl"s improve the situation considerably, but they still don't do EOT handling perfectly; Alex White's modifications to the driver to selectively permit reading/writing past EOT makes the EOT feature fully usable (so you can write EOT labels after the EOT mark, while still protecting programs that don't know that tapes are special from running the tape off the reel). 2) not all tape drives may permit small amounts of data (like trailer labels) to be written past the EOT. If these facilities were there, "dump" could write its end-of-tape label when it encounters an EOT, instead of when its count runs out; that would also mean that if you were "dump"ing to a file it would never think it had to change tapes. "tar" and "cpio" have end-of-archive indicators, so the program wouldn't even have to care about EOT, except to change volumes; an EOT encountered on an I/O operation would be a indication to tell the operator to mount a new tape and retry the operation. Simple, requires little change to "tar" (none to "cpio", if the code that's there already works) and permits the program to work perfectly fine on non-tapes. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy