Path: utzoo!attcan!uunet!lll-winken!csd4.milw.wisc.edu!dogie.macc.wisc.edu!indri!larry!jwp
From: jwp@larry.sal.wisc.edu (Jeffrey W Percival)
Newsgroups: comp.unix.wizards
Subject: Re: read(2) won't move TK50 past tape file mark
Keywords: ultrix tk50 unix tapes
Message-ID: <190@larry.sal.wisc.edu>
Date: 25 May 89 14:57:04 GMT
References: <466@polyof.UUCP> <187@larry.sal.wisc.edu> <2721@helios.ee.lbl.gov> <6975@cbmvax.UUCP>
Reply-To: jwp@larry.sal.wisc.edu.UUCP (Jeffrey W Percival)
Organization: Space Astronomy Lab, Madison, WI
Lines: 27

In article <6975@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes:
>	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.


Just a reminder:  in my original posting I pointed out that we observe
*two* behaviors here:  the documented one AND the "sticky EOF" one.
Ultrix 3.0 and 2.2 on a VS2000 worked as TFM says, but the Ultrix 3.0
on two MVII's had a sticky EOF.

So the phrase "THE Ultrix driver" is not useful.

1. DEC has created both behaviors.  Is one acknowledged by them to be an error?

2. If one is an error, which one?

3. Is a fix in the works?

Enquiring minds want to know!

By the way: I discovered this by trying to read a VMS saveset tape,
which is a multi-file thing.  The vmsbackup program in the uunet
archives assumes the documented behavior of mtio(4).
-- 
Jeff Percival (jwp@larry.sal.wisc.edu)