Berend Tober [[EMAIL PROTECTED]] writes: > That was my point about comparing rsync to sending the entire file > using say, ftp or cp. That is, one might think that sending the > entire file via ftp or cp will produce a exact file copy, however the > actual transmission of the data takes the form of electrical signals > on a wire that must be detected at the receiving end. The detection > process must have some probablilty of false alarm/missed detection > characteristic and so there must be some estimate of the probability > of ftp and cp failing to produce a reliable copy. So while the > software algorithm of ftp and cp are deterministic, there must be > some quantifiable probablity of failure non-the-less. The difference > with rsync is that not only are the same effects of data corruption > at work as with ftp and cp, but the algorithm itself introduces non- > determinism.
Except of course that rsync uses its own final checksum to balance out its risk of incorrectly deciding a block is the same. If the final full-file checksum doesn't match, then rsync automatically restarts the transfer (using a slightly different seed, I believe). Thus, it's fairly accurate to compare rsync to performing an ftp or cp and then doing a full checksum on the file, so one could argue it's actually more reliable than a straight ftp/cp without the checksum. -- David /-----------------------------------------------------------------------\ \ David Bolen \ E-mail: [EMAIL PROTECTED] / | FitLinxx, Inc. \ Phone: (203) 708-5192 | / 860 Canal Street, Stamford, CT 06902 \ Fax: (203) 316-5150 \ \-----------------------------------------------------------------------/ -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
