when rsync fails to read part of a file, it silently transfers blocks of zero bytes instead of the actual data. This renders rsync useless for most kinds of backup applications, because in case of a hardware failure, all backups may be already destroyed by blocks of zeros, and you have a hard time to figure out which files are intact (i.e. should contain such blocks) and which are not (i.e. rsync introduced such blocks), because there isn't even a information in any log. I'd suggest to introduce an option --ignore-read-errors which exhibits the current behaviour and fail on read-errors as per default.
Rsync sends zeroes in an attempt to get as much of the new data to the receiver as possible; one could argue that the receiving rsync should take the data from the same offset in the basis file instead. It also sabotages the post-transfer MD4 checksum on lines 355-357 of match.c: /* If we had a read error, send a bad checksum. */ if (buf && buf->status != 0) file_sum[0]++; That will cause the receiving rsync to delete the temporary file on line 641 of receiver.c, leaving the old but valid version of the source file intact. Rsync will produce a message like this: WARNING: <file> failed verification -- update discarded (will try again) So I don't think there's a problem. Wayne, please correct me if I am wrong.
ah, sorry. After double-checking this only happened with 2.6.5, i.e. the current version 2.6.8 actual throws an error message.
Fixed in newer versions.