Xref: utzoo comp.unix.wizards:25360 comp.periphs.scsi:2520
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!apple!voder!pyramid!ctnews!risky!!scott
From: scott@.convergent.com (Scott Lurndal)
Newsgroups: comp.unix.wizards,comp.periphs.scsi
Subject: Re: My Exabyte has a personality!  It hates cp!  HELP!!
Message-ID: <4462@risky.Convergent.COM>
Date: 2 May 91 23:27:17 GMT
References: <1991May2.044713.12583@coplex.uucp>
Sender: root@risky.Convergent.COM
Reply-To: scott@.convergent.com (Scott Lurndal)
Organization: Unisys Network Computing Group
Lines: 24

In article <1991May2.044713.12583@coplex.uucp>, dean@coplex.uucp (Dean Brooks) writes:

|>    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.
|> 

|> Any clues?

It doesn't work because there is a fixed block size on the tape drive and 
no inode to keep the eof information.  When you restore from the tape, you
are going to get all the data up to the next tape block boundary.   cpio 
and tar know this and can deal with it, cp and cat don't and can't.