Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!cbmvax!grr
From: grr@cbmvax.UUCP (George Robbins)
Newsgroups: comp.unix.wizards
Subject: Re: read(2) won't move TK50 past tape file mark
Keywords: ultrix tk50 unix tapes
Message-ID: <6975@cbmvax.UUCP>
Date: 25 May 89 03:21:48 GMT
References: <466@polyof.UUCP> <187@larry.sal.wisc.edu> <2721@helios.ee.lbl.gov>
Reply-To: grr@cbmvax.UUCP (George Robbins)
Organization: Commodore Technology, West Chester, PA
Lines: 24

In article <2721@helios.ee.lbl.gov> envbvs@epb2.lbl.gov (Brian V. Smith) writes:
> According to the manual entry for mtio(4) on Ultrix 3.0
> (quoted w/o permission):
> 
>      done with a tape ioctl call.  A zero byte count is returned
>      when a tape mark is read, but another read will fetch the
>      first record of the next tape file. When a file open for
>      writing is closed, two end-of-files (EOF) are written.

		And the tape is repositioned after the first of
		the two tape marks...
 
> Therefore, you could expect to get 0 bytes read for two reads 
> (because of two possible EOF's on the tape), but after that it should 
> read the next file.

	No, the bug is most likely that the Ultrix driver *is* playing
	the sticky EOF game.  If the program closed/opened the input file
	it would probably work fine, though the man pages imply this is
	not necessary.
-- 
George Robbins - now working for,	uucp: {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing	arpa: cbmvax!grr@uunet.uu.net
Commodore, Engineering Department	fone: 215-431-9255 (only by moonlite)