Path: utzoo!attcan!utgpu!utstat!jarvis.csri.toronto.edu!rutgers!cmcl2!polyof!john
From: john@polyof.UUCP ( John Buck )
Newsgroups: comp.unix.wizards
Subject: Re: read(2) won't move TK50 past tape file mark
Summary: seems ok to me
Keywords: ultrix tk50 unix tapes
Message-ID: <466@polyof.UUCP>
Date: 24 May 89 18:17:46 GMT
References: <187@larry.sal.wisc.edu>
Organization: Polytechnic University, Farmingdale NY
Lines: 45

In article <187@larry.sal.wisc.edu>, jwp@larry.sal.wisc.edu (Jeffrey W Percival) writes:
> ... 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

I would not expect it to do what you said.

> 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
>	...
> Jeff Percival (jwp@larry.sal.wisc.edu)

Generally, most tape drivers I've dealt with, require you to close(2)
the tape device, then re-open it.  Closing the device (on the no-rewind
device) causes the tape to advance past the next EOF mark.  When you
re-open the device, the next read you do will start at the next "file"
on the tape.

Attempting to read(2) past the EOF mark continues to generate "0" byte
reads, as it should.

What you probably want to do is:
	open(no-rewind-tape); read(); read(); read(); close();
	open(no-rewind-tape); while(read() != 0){ ... }
	close();

Perhaps DEC changed the way the tape driver works for different type
machines (tape drives?)?

John Buck
john@polyof.poly.edu