Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!gatech!ulysses!ggs From: ggs@ulysses.homer.nj.att.com (Griff Smith) Newsgroups: comp.bugs.4bsd Subject: Re: tmscp tape drives give "hard error" on reading too small a record Message-ID: <2426@ulysses.homer.nj.att.com> Date: Mon, 20-Apr-87 16:54:59 EST Article-I.D.: ulysses.2426 Posted: Mon Apr 20 16:54:59 1987 Date-Received: Tue, 21-Apr-87 03:24:04 EST References: <1681@husc6.UUCP> <2412@ulysses.homer.nj.att.com> <1696@husc6.UUCP> Organization: AT&T Bell Laboratories, Murray Hill Lines: 54 Keywords: tmscp, TU81, DEC Summary: UNIX System tape semantics is an oxymoron In article <1696@husc6.UUCP>, dudek@endor.UUCP writes: > 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). 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. Sorry to be so abrasive in the summary, but I think it is dangerous to invoke "that's the way we've always done it" in cases such as this. Using similar reasoning, UNIX tape drivers might be required to crash the system when they encounter bad blocks because some of them already do it. Lost data is lost data; people who depend on "benign" cases will be bitten by their bad habits. Calling it a standard is cancerous. > 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. Since the default blocksize for > dd is 512, and the tape blocksize was larger, the device reported a hard error. So fix the script and scream at the supplier of the software. They took advantage of a bug that has been replicated into most drivers. The "bs" option of "dd" provides a portable solution. > 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? No, it would just require another error code to be added to errno.h. How about EDATALOST? For something as serious as corrupted data, you want the normal case to be an error. It should be possible, but non-trivial to override the error condition. > I suppose ioctl can be used for the application above, but that would > require two system calls for every device write. > 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? The data can be kept in the user > structure and copied to some well-known address in the processes' virtual > address space (blech, kludge, any better ideas?). If you did add extended error status in some portable form (there is already a non-portable version in the BSD drivers), you would only have to get the status after an error. > Glen Dudek > Computer Facilities Manager > Aiken Computation Lab -- Griff Smith AT&T (Bell Laboratories), Murray Hill Phone: 1-201-582-7736 UUCP: {allegra|ihnp4}!ulysses!ggs Internet: ggs@ulysses.uucp