In article <esgm705rk3sfkvdp3s8vbetsefkge5777o@4ax.com>,
Jeff Liebermann <jeffl@comix.santa-cruz.ca.us> wrote:
>On Mon, 12 Apr 2004 14:13:07 -0700, "G3WIP" <g3wip@deadspam.co.uk>
>wrote:

>>Thanks. Lots of ideas there.

>>J.P: I would be interested to know what is so awful about cpio
>>to tape. The answers may be amusing and alarming

>Would J.L. be ok? The problem with cpio, tar, pax, dd, and such is
>that threre's no mechanism for verifying that your copy arrived in one
>piece, or that your tape drive didn't "error correct" the data into
>oblivion. Good, fast, cheap. Pick two.

>http://aplawrence.com/Reviews/supertar.html

And in cpio vs tar, the latter is pretty basic in construction,
more like a huge concantentaion of files written consecutively.
As such it's easier to reconstruct a broken tar file with system
tools than it is a cpio file.

And in addition to Jeff's comment on a drive 'error correcting' the
data, there is also the other possibility.

Data can [not often but it can] be corrupted from the time it is
read from the disk and before it is delivered to the tape
controller. Then when the tape controller gets it, it builds a
crc/checksum on data with errors, so if you if you think a tape is
good just by reading end to end to see if there are no CRC errors,
you have what you >think< is a good backup, when in reality it is
corrupt.

The supertar solutions are the only way to go except for the
dedicated hacker [using the original definition] who builds their
own bit-level verifications routines, or finds the source on
the 'net for one. In the Olden Dayze when BackupEdge and LoneTar
were not available on one platform I used, and old SysV.2 as I
recall, and I had a program from alt.sources written by Warren
Tucker, and I used it for bit-level verifies for floppy saves.

Not worth in today's world.

Bill

--
Bill Vermillion - bv @ wjv . com