Brian Keene's Tape Reading Troubleshooting Guide

First, let me set some ground rules (let me ASS-U-ME).
  • You have a tape drive.
  • Your tape drive is the same type as your outside source's (i.e. 8mm, 4mm, QIC, etc.).
  • If your drives are both 4mm tape drives, they are both using the same recording format (i.e. dd1, dd2, dd3).
  • Your both using the same command (i.e. tar, cpio, etc.).

What do you do if you can't read a tape sent to you from an outside source?

    If your trying to get data from an SGI to an HP system, use the following command to WRITE the tape:

        dd if=/dev/rmt/#m bs=20 | tar xvf -

      where the # is the device number of the tape drive.

      You could also try the "shar" command. That will create one file which you can unpack with "sh".

      When creating a tar file on an SGI machine that will be used on other platforms (i.e., HP and Sun) there is an extra argument which must be used. I believe it is -s which has to do with byte wapping. Have your supplier double check this argument setting.

      Sometimes, adding an extra file ("touch z_end") to the directory to act as a buffer usually limits block size problems to losing an extraneous file.

    If your trying to get the data onto an HP system from a tape written on an SGI, use ONE of the following commands to READ the tape. If the command you picked doesn't work, try another one. It may just be a matter of getting the right combination of commands and options.

        pax -b 512K -rvf /dev/rmt/omn
        tar ivb 20
        dd if=/dev/ bs=20 conv=swab | tar xvf -
        dd if=/rmt/0m ibs=512k obs=10k | tar -xvf -

      Here is some background information on how SGI's and HP's store information (it and the 10k command given are what solved my problem.)

      Check out the HP FAQ on HP's setup w/Pro. Basically the item from the FAQ is:

      10. How can I read a DAT tape created with tar on an SGI system? The secret here (at least in this case) is to byte-swap the tape before passing it to tar. The following command will read an SGI tar tape:

        dd if=/rmt/0m conv=swab | tar -xvf -

      Byte swapping is believed to only be necessary if the device which created the tape was a swapping one. (Swapping tape devices are the default on IRIX 4, but not in IRIX 5). If the SGI is running IRIX 5.0x or above, a large (512K) block size is used:

        dd if=/rmt/0m ibs=512k obs=10k | tar -xvf -

      By default, the HP-UX tar command uses a blocking factor of 20 when writing tapes. Tar uses 512-byte blocks, so this means the tape block size is 10240 bytes (the 10k in the above command). On HP-UX, 20 is also the maximum blocking factor for tar. That is why it is necessary to use a tool like dd to read arbitrarily large blocks from the tape, and output them in 10k-sized chunks.

    If you were able to read the tape but are having other problems. Try these other suggestions.

      Pro/E does not tolerate carriage return characters that can be added when you transfer files using ftp on a DOS or Windows based machine. It complains "partname cannot be retrieved". On HP machines, those extra characters are apparently ignored. There's an IRIX command to get rid of these, see the man page on "to_unix". To look for the C/R's, look at a part file with the vi editor. It will display a control-M ("^M") for each C/R.
    If a vendor is FTP'ing you files through a BBS or on an FTP site. Consider the following:

      A lot of people have trouble with basic upload procedures. Your vendor needs to create the tar file, rename it to parts.tar (DOS filename rules), and FTP the data file to upload it to the BBS/FTP site.
      When they FTP the file. They must remember to FTP it in binary mode, and limit the filenames to DOS 8.3 format. They can compress the tar file if they want to, but they will need to tell you that you will need to uncompress the file before extracting the data from the "tar" file. Suppressing most of the features can also reduce the size of the data significantly.
      One suggestion made to troubleshoot a problem with an FTP'ed file is that you may want to find out how many bytes the original file was, and how many you received. For binary mode, they need to be the same.
      If the file sizes are the same, and the file was compressed. Try uncompressing the file. If that won't work, the file is damaged. If it does work, and the file seems like gibberish, you may need to swap bytes. The 'dd' command will do this:

        dd if=foo conv=swab of=foo.new

      Another command might be:

        dd if=partfile.tar conv=swab | tar xvof -