setblk <n>

Set the tape drive's SCSI block size to <n> bytes. (NOTE: if you are using your OS's native tape driver, THIS IS EVIL!).

fsf <n>

Go forward by <n> tapemarks.

bsf <n>

Go to immediately previous the <n>th previous tapemark. (WARNING: This probably doesn't do what you expect -- e.g. if you are immediately after a tapemark and type 'bfs 1', it moves to immediately *before* that tape mark, for a sum total of zero effective movement!).

eod

Go to end of data.

rewind

Rewind the tape drive.

eject

Eject the tape currently in the drive.

erase

Does a *short* erase (warning: does NOT work on all drives!).

mark <n>

write <n> filemarks ( 'mark 0' flushes the drive's buffers ).

seek <n>

Seek to a logical position <n> that was reported by a previous 'tapeinfo' command.

write <blocksize>

write blocks from stdin to the tape. Chunk the data into <blocksize>-sized chunks. *DOES NOT WRITE OUT A TAPEMARK!* (you will need to use a subsequent mark 1 command to write out a tape mark).

read [<blocksize>] [ <#blocks/#bytes> ]

read blocks from the tape, write them to stdout. If we are in variable block mode, <blocksize> should be zero (note: The maximum block size we currently support in variable block mode is 128K, MAX_READ_SIZE will need to be turned into a settable variable to allow bigger reads). If <blocksize> is ommitted, we assume that we're in variable block mode, and that we are going to read from tape until we hit a tapemark or end of partition or end of tape.

The SCSI read and write routines are based upon those that Richard Fish wrote for Enhanced Software Technology's BRU 16.1 product, substantially modified to work in our particular environment (in particular, all the variable block stuff is new since BRU only does fixed block reads and writes, and the BRU code uses bitmasks rather than bitfields for the various flags and such in return values, as well as the BRU code having a different SCSI API and having variable names considerably shorter than the rather sesquipedalian 'mtx' identifiers). As required by 'mtxl.c', these routines are licensed under the GNU General Public License.

for scsitape read 0 <n> where you are doing variable-block-size reads and wish for <n> bytes, it instead reads one and exactly one block from tape and prints that (no matter what its size). Use 'dd' on the output of scsitape if you want finer control. scsitape read 0 attempts reads of MAX_READ_SIZE, which is currently 128K. If blocks on tape are larger than 128K, only the first 128K will be read -- the remainder will be silently dumped in the toilet. This program does not interact well (or at all :-) with your OS's native tape driver. You will likely see weird things happen if you attempt to intermingle scsitape commands with native tape driver operations. Note that BRU 16.1 for Solaris (and possibly others, but Solaris I know about) will have a 'scsi' keyword to bypass the native tape driver and write via direct uscsi commands, so if you use BRU 16.1 to write your actual tape archives. (Assuming that BRU 16.1 has been released at the time that you read this).