Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!ames!pacbell!att!ihlpb!res
From: res@ihlpb.ATT.COM (Rich Strebendt)
Newsgroups: comp.unix.wizards
Subject: Re: read(2) won't move TK50 past tape file mark
Summary: Should not be able to read past EOF !!!
Keywords: ultrix tk50 unix tapes
Message-ID: <10530@ihlpb.ATT.COM>
Date: 24 May 89 21:54:58 GMT
References: <187@larry.sal.wisc.edu>
Organization: AT&T Bell Laboratories - Naperville, Illinois
Lines: 56

In article <187@larry.sal.wisc.edu>, jwp@larry.sal.wisc.edu (Jeffrey W Percival) writes:
| I have a TK50 tape with 3 80-byte records followed by a tape file mark,
| which is in turn followed by many 8192-byte records.  I wrote a little
| C program that does a read(2) in a tight loop, and reports the number
| of bytes read.    We expect this:
| 
| 	80 bytes read
| 	80 bytes read
| 	80 bytes read
| 	0 bytes read
| 	8192 bytes read
| 	8192 bytes read
| 	...
| 
| Right?  We get this output on a VS2000 with Ultrix 2.2, and a VS2000
| with Ultrix 3.0.  However, on 2 of our MicroVAX II's running Ultrix 3.0,
| we see this:
| 
| 	80 bytes read
| 	80 bytes read
| 	80 bytes read
| 	0 bytes read
| 	0 bytes read
| 	0 bytes read
| 	0 bytes read
| 	0 bytes read
| 	0 bytes read
| 	0 bytes read
| 	0 bytes read
| 	...
| 
| It looks like the read(2) is not getting past the file mark.  This
| could be a problem in the C routine read(2), the Ultrix system, or
| in the TK50 controller.  Has anyone seen this, or know what's going on?

In order to read two files off of a tape on any reasonable system, the scenario
should be the following:

	Open the device w/o rewind on close
	Read the first file -- perhaps until EOF is encountered
	Close the device
	The tape unit should now position the tape with the head just past the
		EOF mark.
	Open the device (typically with rewind)
	Read the second file until EOF is encountered or until program is
		happy
	Close the device and watch the tape reel spin to BOT

On all of the tape controllers with which I have worked, if EOF has been
encountered the controller does not attempt to read the tape.  It just sends
back another "you already found EOF, dummy" indication.  This is to protect
against a program ignoring EOF and attempting to read a couple thousand feet of
possibly blank tape -- one heck of an Inter-Block Gap!!

				Rich Strebendt
				...!att!ihlpj!res