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

[Keith Pyle]

The original post on this topic in message <187 at larry.sal.wisc.edu> by
jwp at larry.sal.wisc.edu (Jeffrey W Percival) noted a problem when reading
a tape with multiple files under Ultrix 3.0.  He found that read(2)
returns 0 bytes whenever an EOF is encountered as expected but that it
continued to return 0 on subsequent calls.  This behaviour was questioned
as it was expected that the subsequent reads would return data from the
following file of the tape.

In article <2721 at helios.ee.lbl.gov>, envbvs at epb2.lbl.gov (Brian V. Smith)
writes:
>According to the manual entry for mtio(4) on Ultrix 3.0
>(quoted w/o permission):
>
>     ... 
>     done with a tape ioctl call.  A zero byte count is returned
>     when a tape mark is read, but another read will fetch the
>     first record of the next tape file. When a file open for
>     writing is closed, two end-of-files (EOF) are written.
>
>Therefore, you could expect to get 0 bytes read for two reads 
>(because of two possible EOF's on the tape), but after that it should 
>read the next file.

This is essentially the same statement found in the mtio(4) documentation
for SunOS 4.0 and DYNIX 3.0.12, and in mt(7) for HPUX.  More important
to this discussion, this is the observed behaviour on these systems.
There is one point Brian did not mention: when a close is issued, two
EOFs are indeed written, but the tape will be positioned between them
if the device is a no-rewind device.  Thus, two successive files may have
only one intervening EOF if the device was of the no-rewind type.

Clearly, the documented behaviour is for read(2) to return 0 once for each
EOF found on the tape.  I recently wrote a set of programs for tape
duplication that runs on most of the Unix systems here (Sun, Sequent,
Ultrix, HP) and Ultrix was the only one that did not function in
accordance with the documentation.  As pointed out by some others
responding to the original post, you can deal with this situation (can
you spell B-U-G?  I thought that you could! :-)) by (1) use a no-rewind
device, (2) close and reopen the device on encountering an EOF.  Another
technique (kludge) is to perform an MTIOCTOP ioctl call specifying a
forward space (MTFSF) of 0 files.  The use of this ioctl call in this
way may not work for all systems according to the person who described
it to me.  In either case, the handling of an EOF is substantially
slower than on systems which do what they say they will do.

-- 
-----------------------------------------------------------------------------
Keith Pyle                                UUCP: ...!cs.utexas.edu!execu!keith
Execucom Systems Corp., Austin, Texas     Internet: execu!keith at cs.utexas.edu
                                               keith%execu.uucp at cs.utexas.edu
Disclaimer: What??  You actually believed me?
-----------------------------------------------------------------------------