Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!sri-spam!ames!oliveb!sun!gorodish!guy
From: guy%gorodish@Sun.COM (Guy Harris)
Newsgroups: comp.bugs.4bsd
Subject: Re: tmscp tape drives give "hard error" on reading too small a record
Message-ID: <17000@sun.uucp>
Date: Mon, 20-Apr-87 13:07:27 EST
Article-I.D.: sun.17000
Posted: Mon Apr 20 13:07:27 1987
Date-Received: Tue, 21-Apr-87 02:39:56 EST
References: <1681@husc6.UUCP> <2412@ulysses.homer.nj.att.com> <1696@husc6.UUCP>
Sender: news@sun.uucp
Reply-To: guy@sun.UUCP (Guy Harris)
Organization: Sun Microsystems, Mountain View
Lines: 66
Keywords: tmscp, TU81, DEC

>I realize the dangers of silently truncating data, but UNIX semantics for raw
>tape devices require this behaviour (at least, all such raw tape drivers I've
>ever seen behave this way).

There is a significant difference between

	"UNIX semantics for raw tape devices require this behavior"

and

	"all raw tape drivers I've ever seen behave this way".

Does it say anything in the manual about smaller-than-block-size
reads?

>Until the interface is changed to allow more out-of-band information to be
>passed along with the data (e.g., data truncated, physical end-of-tape,
>etc.), vendors need to stick with existing semantics.

Not if the *overall* cost of sticking with existing semantics is
higher than the cost of changing.  Griff has already testified that
there can be a cost to silently ignoring errors.

Besides, I think other 4BSD tape drivers also complain about
smaller-than-block-size reads.

>I found this problem when a remote software installation broke because the
>installation assumed 'dd if=/dev/rmt4 of=/dev/null' would successfully
>skip a tape file independent of blocksize.

First of all, that "dd" won't successfully skip files on most UNIX
systems.  Try 'dd if=/dev/nrmt4 of=/dev/null'.  Second of all, a
better choice might be

	if [ -x /bin/mt ]
	then
		mt -t /dev/nrmt4 fsf 1
	else
		dd if=/dev/nrmt4 of=/dev/null
	fi

A "skip forward one file" command doesn't care how big the blocks
are, and runs much faster than reading the file, at least with a
vanilla "dd" (and possibly faster even than Griff's improved "dd").
(And, before somebody complains that repeatedly checking for the
existence of "/bin/mt" would slow it down too much - an assertion I
tend to doubt - you can test it once and set a shell variable
instead.)

>How can we change the interface to such devices to allow reporting these kinds
>of errors?  Do we need to change the system call interface to do this?  I
>suppose ioctl can be used for the application above, but that would require
>two system calls for every device write.

Nope.  Two system calls for every device read or write *that reports an
error*.

>How about another int (or preferably, a more complex structure which hides
>the data better and allows some extensibility) analagous to errno, but which
>is valid after all system calls and can be used to pass such information?

No.  There are already too many global variables in the UNIX system
call interface.  I'd rather get rid of the ones we already have, by
making the "conventional" UNIX calls just be wrappers around calls
that *don't* muck with global variables, than introduce new global
variables.