Xref: utzoo comp.unix.wizards:25372 comp.periphs.scsi:2527
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!ogicse!cvedc!mcspdx!adpplz!martin
From: martin@adpplz.UUCP (Martin Golding)
Newsgroups: comp.unix.wizards,comp.periphs.scsi
Subject: Re: My Exabyte has a personality! It hates cp! HELP!!
Message-ID: <714@adpplz.UUCP>
Date: 3 May 91 16:28:54 GMT
References: <1991May2.044713.12583@coplex.uucp>
Followup-To: comp.unix.wizards
Organization: ADP Dealer Services R&D, Portland, OR
Lines: 26

In <1991May2.044713.12583@coplex.uucp> dean@coplex.uucp (Dean Brooks) writes:
>   If I do the following to place a file on to the [exabyte] 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.  


The exabyte is (internally) fixed very large block. Filemarks are only
found between blocks. When you cp the file onto the exabyte, somebody
somewhere is giving you padding for the last block. When you read it
back, you get the padding ABSOLUTELY FREE!. You would find the same
effect on a cartridge tape, but not quite as much extra data (512).

cpio, because it is designed to pack multiple data sets into a single
physical file, has byte counts for the files, so when you cpio one
or more files out and back, cpio cheerfully ignores the padding.
Use cpio (which is also ABSOLUTELY FREE) or ar or tar or maybe invent your
own exciting storage/retrieval mechanism.


Martin Golding    | sync, sync, sync, sank ... sunk:
Dod #0236         |  He who steals my code steals trash.
A poor old decrepit Pick programmer. Sympathize at:
{mcspdx,pdxgate}!adpplz!martin or martin@adpplz.uucp