My Exabyte has a personality! It hates cp! HELP!!

[Glenn Shapland]

In article <1991May2.044713.12583 at coplex.uucp>, dean at coplex.uucp (Dean
Brooks) writes:
|> 
|>    We just recently acquired an Exabyte 2.3 gig tape drive for our
|> Motorola SYS V.3.2 (V/88) 8864 system, and I have noticed something
|> unusual.
|> 
|>    If I do the following to place a file on to the tape:
|> 
|> $ cp /tmp/BIGFILE /dev/exabyte
|> 
|>    And then immediately do the following to extract it again:
|> 
|> $ cp /dev/exabyte /tmp/newfile
|> 
|>    The two files will have different lengths, varying anywhere from
|> 1,000 bytes difference to 38,400 bytes difference.  *However*, if I
|> use "cpio" to backup the file and then restore it, it works perfectly.
|> 
|> I have tried this test over and over with different files, and it *never*
|> works with the "cp" or "cat" command, but *always* works with cpio.
|> 
|> Is there a problem with "cat" or "cp" not doing an fflush or something
|> ignorant like that?  By the way, the /dev/exabyte file is a character
|> based device, not a block based device.
|> 
|> Any clues?
|> 
|> --
|> dean at coplex.uucp (Dean Brooks)
|> Copper Electronics, Inc.
|> Louisville, Kentucky

cp and cat are typically not a preferred way to store data on a tape.
The reason is most cartridge tape formats only support fixed blocks (512
for QIC).
This means that a file written with a utility that does not keep track
of the size of files, will never be read back with the same size as
the original file (unless filesize mod tapeblocksize == 0). Use tar or
cpio. You can test for this problem by taking a file that you read back
from the tape drive, write it to tape drive, read it back and compare
these two files. These two files should be the same since they should
be an even number of tape blocks long.

glenn at ncd.com