russell@ccu1.aukuni.ac.nz (Russell J Fulton;ccc032u) (03/07/91)
I have been trying to implement a system to enforce tape label checking for our backup system. If I first verify that the operators have mounted the right tape by reading the label which has been previously written on the tape and then try to write to the tape I get an I/O Error. If however I rewind the tape after reading the label and then fsf the tape all works as expected. i.e. It would appear that one must rewind the tape when switching between reading and writing. Is this behavior intentional? On other systems I have had programs that read their way down to the end of a tape and then appended data. Is this the reason why -a option of tar does not work? Thanks, Russell. -- Russell Fulton, Computer Center, University of Auckland, New Zealand. <rj_fulton@aukuni.ac.nz>
jeremy@perf2.asd.sgi.com (Jeremy Higdon) (03/08/91)
In article <1991Mar7.005651.16891@ccu1.aukuni.ac.nz>, russell@ccu1.aukuni.ac.nz (Russell J Fulton;ccc032u) writes: > I have been trying to implement a system to enforce tape label checking for > our backup system. > If I first verify that the operators have mounted the right > tape by reading the label which has been previously written on the tape and > then try to write to the tape I get an I/O Error. > > If however I rewind the tape after reading the label and then fsf the tape > all works as expected. > > i.e. It would appear that one must rewind the tape when switching between > reading and writing. Is this behavior intentional? On other systems I have > had programs that read their way down to the end of a tape and then appended > data. > > Is this the reason why -a option of tar does not work? > > Thanks, Russell. > > -- > Russell Fulton, Computer Center, University of Auckland, New Zealand. > <rj_fulton@aukuni.ac.nz> The Exabyte does not allow write after read. It allows writes only from BOT, bottom of filemark, or blank tape. Your fsf must happen to position you at blank tape. So the behavior that you're seeing is correct.
olson@anchor.esd.sgi.com (Dave Olson) (03/08/91)
In <1991Mar7.005651.16891@ccu1.aukuni.ac.nz> russell@ccu1.aukuni.ac.nz (Russell J Fulton;ccc032u) writes: | I have been trying to implement a system to enforce tape label checking for | our backup system. | If I first verify that the operators have mounted the right | tape by reading the label which has been previously written on the tape and | then try to write to the tape I get an I/O Error. | If however I rewind the tape after reading the label and then fsf the tape | all works as expected. | i.e. It would appear that one must rewind the tape when switching between | reading and writing. Is this behavior intentional? On other systems I have | had programs that read their way down to the end of a tape and then appended | data. Yes, it is intentional. Most non-9track drives (NOTE: not the driver, the actual drive) don't support arbitrary append. QIC only allows append at EOD, 8mm at EOD, and the BOT side of FM's. In general, on SGI machines, the use of mt feom (or ioctl equivalent) allows appending (as a new tape file) at the end of a tape. For 8mm, you can also append via mt fsf #; mt bsf 1; to append at an arbitrary filemark, or use the technique above. The only way we allow write after read on the same open is when executing these ioctls (and others that amount to spacing to FM or EOD). This applies even to the SCSI 9 track; I'm not sure about the Pertec (xm) 9 track. -- Dave Olson Life would be so much easier if we could just look at the source code.