Xref: utzoo comp.unix.wizards:25385 comp.periphs.scsi:2528 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!decwrl!infopiz!lupine!bryant!glenn From: glenn@bryant.NCD.COM (Glenn Shapland) Newsgroups: comp.unix.wizards,comp.periphs.scsi Subject: Re: My Exabyte has a personality! It hates cp! HELP!! Message-ID: <5374@lupine.NCD.COM> Date: 3 May 91 19:26:48 GMT References: <1991May2.044713.12583@coplex.uucp> Sender: news@NCD.COM Reply-To: glenn@bryant.NCD.COM (Glenn Shapland) Followup-To: comp.unix.wizards Lines: 46 In article <1991May2.044713.12583@coplex.uucp>, dean@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@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@ncd.com