Data corruption check

[Matt McCutchen]

On 9/18/07, Fabian Cenedese <Cenedese at indel.ch> wrote:
> I was wondering what happens if a file that is regularly synched but
> seldom changes gets corrupted in the copy.

Are you referring to rsync writing corrupted data to the destination
file or a problem with the destination filesystem or disk causing the
file to read as data different from what was written?

> As it seldom (or never)
> changes the mod time will always be the same. But if the content
> changes (bit flip, bad HD...) will rsync get this and synch it again?

No...

> Would I need the -c (crc) flag for this to work? That of course slows
> things down quite a bit. Is this the only way to ensure that the
> contents are the same on both sides?

Yes, yes.  The only way to check whether a bit of the file has flipped
due to HD or filesystem flakiness is to read the entire file, which is
what -c does.

> There's also the -I, --ignore-times switch. If I use this but without -c
> what method is used for checking then? Or does -I imply -c?

-I rewrites the destination file no matter what, while -c computes its
MD4 or MD5 checksum first and then rewrites it only if its checksum
differs from that of the source file.  Either option gives the same
end result for the destination file.  However, they may have different
performance (-c uses more disk reading but potentially less disk
writing and slightly less network traffic), and -I logs more transfers
than -c and interferes with --link-dest.

Matt