rsync -auIn not doing what I expect (rsync 2.6.3)

[Bart Brashers]

Hi,

Some of my files recently became corrupted due to disk I/O errors (bad
SCSI terminator).  I've fixed my I/O errors, run fsck, and am now
wanting to restore from my rsync backup.  

However, some time has passed, and users have continued working,
creating new files, in some cases with the same filename as existed
before the disk I/O problems started.  E.g. editing a .c file to fix a
bug.

Some of the files are corrupt, even though they have the same file sizes
and timestamps (often years ago) as the backup files.  I've spot-checked
and confirmed that the backup files are not corrupt.

Ok, this should be easy, right?  Let's see what would happen:

rsync -auIn backup:/archive/home /home

The "-I" tells rsync to ignore the timestamps (the corrupt files still
have old timestamps) and the file sizes (the corrupt files are the same
size as the backup non-corrupt files) and do the checksums to determine
which files need to be transferred.

The "-u" tell rsync not to overwrite newer files.  I've over-written old
files, and I don't want the backup files to clobber these.

However, it appears from the lines of output that rsync spews out, that
it would clobber newer files.  Does turning on "-I" mess up the
time-comparison needed by "-u"?

Also, if I do a manual "diff" between the files that rsync -auIn prints
to std out, most of them show no difference.  Am I correct in assuming
that rsync does not perform the checksum to detect if each file needs to
be transferred when using "-n"?  Is there some way to force it to do the
checksum and tell me which files it would _actually_ transfer?

Thanks,

Bart
---
Bart Brashers, Ph.D.
Air Quality Meteorologist
Geomatrix Consultants, Inc.
19203 36th Ave W Suite 101
Lynnwood WA 98036-5772
425-921-4000 (main)
425-921-4020 (direct)
425-921-4040 (fax)