Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!husc6!mit-eddie!ll-xn!ames!lll-tis!ptsfa!ihnp4!laidbak!guardian
From: guardian@laidbak.UUCP (Harry Skelton)
Newsgroups: comp.unix.questions,comp.unix.wizards
Subject: Re: UNIX tape backup utilities ( SysAdmin from UniSolutions Assoc.)
Message-ID: <1115@laidbak.UUCP>
Date: Tue, 25-Aug-87 12:18:49 EDT
Article-I.D.: laidbak.1115
Posted: Tue Aug 25 12:18:49 1987
Date-Received: Thu, 27-Aug-87 04:15:46 EDT
References: <153@tijc02.UUCP> <1143@ttidca.TTI.COM> <358@mcdsun.UUCP>
Reply-To: guardian@laidbak.UUCP (Harry Skelton(E))
Organization: LAI Chicago
Lines: 41
Keywords: menus security backups
Summary: Verify at loss of time
Xref: mnetor comp.unix.questions:3724 comp.unix.wizards:3888

In article <358@mcdsun.UUCP> fnf@mcdsun.UUCP (Fred Fish) writes:
>
>Have these vendors modified tar/cpio to do actual data
>verification or does their idea of verification mean being able to
>get a listing of the table of contents without getting any errors, or
>possibly extracting all the files into some spare disk partition and
>doing some sort of file comparison?
>
>-Fred

I have worked with tape drives and software under SCO Xenix and 
a couple of other drives under other Xenix's and found one thing that most
end up doing:  read under rewind or write-read durring output.  

A general read under rewind does ok but does not totally insure data but most 
tape problems that I have found have been hard errors anyway.  The write-read
functions do insure data but will cost you in backup time .  

Like 'tar' under any system, most of the Xenix based 'tar' utilities are
streamers (from manufacturer) and are just as stupid as the original tar.
( script does not recieve error from tar although tar said it had problems )

I am certain that this may have been fixed by now but was brain dammaged when
I worked on it (couple of months ago).  

'dd' I can see being able to verify the tape with a streaming readback but
with utilities like 'tar' or 'cpio', I too can't think of a 'good' way of
verification other than a funky readback or write-read function.

Quick question:  Anyone know why 'dd' would not wait for a device?  I have
a tape drive attached to a large unix box (and found this true on other 
systems) and I use dd to read in from the tape.  When the tape drive takes a
moment to advance the tape, dd seems to continue without checking
on the status of the device.  Is this normal?  Is this a problem with the 
device?  Is this a problem with 'dd'?

reply 'RE: dd and devices'

Many thanks...

Harry Skelton