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)
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.