read(2)/write(2) errno for end of 9-track tapes

Alan T. Bowler [SDG] atbowler at watmath.waterloo.edu
Fri Apr 8 10:06:13 AEST 1988


In article <7051 at drutx.ATT.COM> kvt at drutx.ATT.COM (TranKV) writes:
>
>When read(2)/write(2) are used to access a physical device in raw mode
>(9-track tape devices specifically), are there a standard errno's that 
>read(2)/write(2) returns to signify end of physical tapes? Or do they 
>vary among UNIX versions and tape drives? If they are indeed different,
>what one can do in application programs to make them portable when
>changing tape drives or machines? 

Henry Spencer has observed that the mag tape drivers and their status
returns tend to be non-standard.  Part of the reason of course is that
the original Unix drivers ignored end of tape.

That aside I will point out that most tape hardware has NO end-of-tape
status on a read.  On a write, the hardware usually returns 
"successful write, and by the way you just passed the foil marker".
The software is expected to observe the end of tape indication
and write something on the tape that the reader will recognize
as an end of tape.  On the older operating systems, this usually is
an eof marker and a trailer label indicating the name of the reel
that the data is continued on.
   The Unix convention of return statuses from write does not lend
itself well to this concept of "the operation worked but there
is something that requires your attention soon  (i.e. before you
run out of wrapup space)".   I.e. if the write is successful,
then it should be returning the number of bytes written, and so the
programmer doesn't get the idea he should check errno.  If the
write returns -1 to tell the user he should check errno, the 
program has lost the "actual byte count written" data that
the program needs to continue (assuming he is not using a raw device).
The early Unix mag tape drivers solved the problem by ignoring
the end of tape status, and assuming programs would precalculate
a "guestimate" of how much the tape would hold.  Since then
various things have been done depending on the expected use
pattern at individual sites.



More information about the Comp.lang.c mailing list