Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!ncr-sd!greg
From: greg@ncr-sd.UUCP (Greg Noel)
Newsgroups: net.unix,net.unix-wizards
Subject: Re: need help with multi-reel cpio
Message-ID: <465@ncr-sd.UUCP>
Date: Wed, 30-Apr-86 21:57:07 EDT
Article-I.D.: ncr-sd.465
Posted: Wed Apr 30 21:57:07 1986
Date-Received: Sat, 3-May-86 00:06:57 EDT
References: <520@sdcc13.UUCP> <461@ncr-sd.UUCP> <1241@ulysses.UUCP>
Reply-To: greg@ncr-sd.UUCP (Greg Noel)
Organization: NCR Corporation, San Diego
Lines: 44
Xref: watmath net.unix:7735 net.unix-wizards:17878

In article <1241@ulysses.UUCP> ggs@ulysses.UUCP (Griff Smith) writes:
>Well, not quite. The earlier Berkeley drivers (and some of the current ones)
>ignore the condition and let you pull the tape off the reel.

Showing my age, I'll point out that in the V6 system I first worked on, not
only did it ignore EOT, it didn't write tape marks, either.  This shows that
the semantics for tape drives have been evolving to be more compatible.  But
it hasn't gone far enough yet......

>....  The last time I checked, the VAX version
>of System V did it correctly; when the write fails, nothing has been written.
>The 3B20 version returns "out of tape" (ENOSPC) after successfully writing
>the block that spans the reflective strip.

Humpf.  Last I checked, our VAX did it wrong; in fact, that's where I isolated
the problem.  However, the VAX is gone now, so I can't check.  But notice that
if this is true, it requires different actions when switching to a new volume;
in one case, you must re-write the block, but not in the other.  I'd like to
have a \standard/ way.

>........  The 4.3BSD TU78 driver simply sets
>a flag when a write sets EOT status in the controller.  The next time a
>"write" system call is attempted, the driver returns an immediate error.

Yes, this is probably a better scheme, particulary since, as was pointed out
in another article, some tape drives can't backspace.

>........  I prefer having a "write tape mark" ioctl; it will be a no-op
>for a non-tape device, so you can still write device independent code.
>........  You have to have some way of overriding
>the EOT condition so you can write trailer labels.
>.......  You didn't mention proper error recovery,
>informative error codes and program controlled tape positioning operations
>(back space record, skip file, back space file, rewind, etc ..... )

Yea, verily.  I didn't mention it because the specific problem was about
end-of-volume handling, but indeed, the Unix tape semantics are one of the
real (reel?) (sorry) dark corners.  Just like the disk semantics, I would
like to see the tape semantics \standardized/.  It may be that not all
standard-conforming systems would have all functions (like the tape drive
that couldn't backspace), but if they are possible, I would like to have
access to them in a standard way.  Is that too much to ask?
-- 
-- Greg Noel, NCR Rancho Bernardo    Greg@ncr-sd.UUCP or Greg@nosc.ARPA