[comp.sys.ibm.pc] Question about compressing backups

res@cblpe.ATT.COM (Rob Stampfli) (02/10/88)

>> rdo031@tijc02.UUCP (Rick Odle           ) writes:
>> ->MKS gives an example in their manual of doing something like this:
>> ->
>> ->	find /dir -type f | cpio -oc | dd of=a:
>> ->
>> ->the -oa keeps the modification time of the original file.  The real problem
>> ->lies in the fact that dd will not write a large archive to a multi-diskette
>> ->volume.  Also there is no compression of the files involved.  
              ---------------------------------------------------

This is one concern that I have been meaning to put to the net.  I use
a backup scheme that employs data compression.  On first glance it would
only seem logical to do so.  My fear is that should I ever have to rely to my
backup files and then find a disk error (say I cannot read a sector) could
I potentially end up losing many files, rather than just a portion of one?
Does anyone have any information about how robust programs like cpio and
arc are in dealing with these types of problems?

Also, not to change the subject, but,

In article <391@mks.UUCP> alex@mks.UUCP (Alex White) writes:
>Dos:
>	A runs to completion: data copied to RAM disk
>	Switch to B: data copied from RAM disk to B
>Now, with the assumption of a RAM disk, and one which is large enough
>for your largest pipe [I have about a meg] can anyone think of any reason
>that the dos method should be slower in terms of time-to-complete?
>[Certainly not in terms of time-to-first-output].

I would *love* to know how to tell DOS that I am using a RAM disk, but don't
recall ever reading that this could be done.  At least for command.com.  Is
there a way, or does the MKS shell, for that matter, have a way of being
told where to put the interim files created during a piped operation?

Thanks in advance for any input,
Rob Stampfli
cbosgd!cblpe!res