read(2) won't move TK50 past tape file mark

[Griff Smith]

In article <10530 at ihlpb.ATT.COM>, res at ihlpb.ATT.COM (Rich Strebendt) writes:
[deleted description of standard System V tape device driver behavior]
> 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.

Perhaps you haven't used DEC products?

> 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!!

So what?  A well designed controller will time out after about 20 feet.

This is another round in the battle between the `let's protect people
from their stupidity' school and the `give me simple tools that do what
I say' school.  If you have ever tried to debug a damaged tape, the
gratuitous file positioning enforced by the System V drivers can be
maddening.

I have some software that implements IBM tape input access methods.
The software is convenient to use on BSD systems where EOF isn't
sticky; people can use the auto-rewind tape names reliably, even though
each dataset is actually three files.  For the System V version of the
software I have to document the feature that the auto-rewind files must
not be used; the @#$%@# operating system rewinds the tape after I
`close' to get to the next file.

If it is really necessary to have user friendly tape behavior, there
should be some sort of `half-baked' tape device that implements it.
The raw device should do nothing but basic I/O and control operations,
and it should have no strange side-effects.  I would even be happy to
see auto-rewind disappear for the raw device.
-- 
Griff Smith	AT&T (Bell Laboratories), Murray Hill
Phone:		1-201-582-7736
UUCP:		{most AT&T sites}!ulysses!ggs
Internet:	ggs at ulysses.att.com