Re: Disk Muncher

[mjmahon@aol.com (MJMahon)]

My guess is that everyone has already made up their mind
about Disk Muncher, but...

Digital data is frequently copied many times in the course of
its use, and the design of _any_ copy utility should aim to
perform copying _absolutely flawlessly_, within the limits
of the technology.  This is why any copy program should,
by default, read back copied data and verify that it is
identical to the original if there is any possibility of an
error (as there is on disk).

I suspect that this was not the motivation of the author of
Disk Muncher, who apparently was more interested in
speed than accuracy.  Those who do not keep backups
of important data value speed (when things work) over
speed when they don't work.  ;-)

A hundred good copies and one bad one is a terrible record
in my book--unless you routinely make _two or more_
copies of important data, since 1 chance in 10,000 or 1,000,000
of an unrecoverable error might be sufficient for many
purposes.

>On Wed, 20 Jan 1999 02:28:08 +1100, richard.b@genie.com (Richard Bennett)
>wrote:
>
>> All versions of Disk Muncher disabled checksum and trailer validation,
>> making disk copying completely unreliable yet to the naive seemingly
>> faster and more reliable. Serves anyone right who actually used the thing.
>
>"Completely unreliable" is an exaggeration, I think. I used Disk
>Muncher quite a lot for some time, and it worked very well. In fact,
>when I started using Locksmith's fast disk backup (which does verify
>the checksums and prints an error diagnostic if it has to re-read a
>sector due to a checksum error), it confirmed that checksum errors
>were extremely rare on my system (unless the disk itself had a weak
>spot).
>
>Paul Guertin
>pg@sff.net



-michael

 Email:  mjmahon@aol.com
 Home page:  http://members.aol.com/MJMahon/