Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site ulysses.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!ggs
From: ggs@ulysses.UUCP (Griff Smith)
Newsgroups: net.unix
Subject: Re: write(2) to tape with odd byte count
Message-ID: <1157@ulysses.UUCP>
Date: Sun, 8-Dec-85 12:04:39 EST
Article-I.D.: ulysses.1157
Posted: Sun Dec  8 12:04:39 1985
Date-Received: Mon, 9-Dec-85 03:53:06 EST
References: <1758@uwmacc.UUCP> <320@brl-tgr.ARPA> <1156@ulysses.UUCP> <393@brl-tgr.ARPA>
Distribution: net
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 54

> Oh, boy!  Magtape driver wars!
> 
...
[deleted for brevity]
...
> I hope they fix the driver so it moves to the next tape mark when
> closed in non-rewind mode.  It's great fun to get the tail of a
> file overwritten because of this misdesign feature.

I hope they don't!  This feature of the System V drivers makes it
impossible to do serious tape hacking (besides, since when did UNIX
systems try to protect users from their own carelessness -) ).  The real
flaw is with tar and cpio, both of which stop at end of data instead of
reading the tape mark that should immediately follow.  When the "skip
to end of file on close" feature is implemented, the following things
can happen:

1.	Suppose I have just gotten a large multi-file distribution tape
	(the System V emulation package will do just fine).  I have skipped
	to the fourth file (which took 5 minutes on the toy 25ips streamer
	I'm stuck with), then I want to verify that I am looking at the
	right file.  I enter "cpio -ictB < /dev/rmt/0mn", verify that the
	right names are coming out, then hit break.  Nothing happens; the
	^%&$^&% operating system is skipping to the end of the file.  I get
	to wait another five minutes for it to find the tape mark, then a
	third five minutes while I wait for the back space file to finish.
	If the tape drive had stopped dead in its tracks, I would have
	re-positioned it in about 15 seconds.

2.	Worse, suppose I have just gotten 100 mbyte of critical data on a tape,
	and block number 100 (out of 10000) is hopelessly munged.  If I am
	using one of the System V drivers, it will try to read the block a few
	times (six, for the VAX TU78 driver), then return "fatal I/O error".
	It also sets an internal flag that makes all subsequent attempts to
	read fail.  I am now stuck;  I can't read any of the data after the bad
	spot.  If I close the tape file, the tape will be re-positioned.  I
	can't even skip over the bad data with "forward space record", since
	System V doesn't have tape control operations.  I might be able to put
	the unit off line, close the file, then re-enable the drive, but don't
	count on it.  As a result of this "convenience" feature, I will have to
	wait a week while a request for a new copy of the tape filters through
	the bureaucracy.

I repeat, the flaws are in cpio and tar.  These commands should read until
physical end of tape.  If there is trash after the presumed end of file,
it should be detected and reported.  Of course, it would also be nice if
the drivers would skip over bad blocks (after reporting the errors) and then
allow subsequent successful reads.
-- 

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