Odd behavior with rsync/ssh/--delete

[Peter Wargo]

I've just about googled my brains out over this one, and banged heads 
with several other SA buddies.

I have a nightly rsync of a DMZ system (Solaris 8 SPARC[1]) to an
internal system (RedHat ES 3.0 [2]).  The internal system runs a cron 
job and pulls
changes off of the DMZ system via ssh.  (To be honest, I've also seen 
this going between two Solaris systems.)

However, my syncs are much bigger then they should be.  I'm getting a
bunch more than I expect - files that haven't changed in a long time are
being deleted and re-sync'd.

Here's an example of the command being used:
rsync -alvx --delete --rsh=ssh root at xxxx:/
/backups0/hosts/xxxx/rsync/

(I use -x to avoid crossing filesystems, as I only back up certain 
ones. The xxxx refers to the hostname of the DMZ system.)

What I see are files like this getting hit every night in the log: 
(real user name blanked.)

[...]
deleting home/xuserx/public_html/vat5.JPG
[...]

Then later the file is written.

If you look at the file on the host:

# ls -la vat5.JPG
-rw-rw-r--   1 xuserx     xgroupx   39816 Jan  3  2000 vat5.JPG

This is strange.  And it's happening for thousands of files.  The 
systems
have the same date and time, I checked that out...

I'm at wit's end on this one.  If anybody has any ideas, I'd be happy 
to hear them.  Also, I can provide more output if desired.

Cheers,

-Pete Wargo

[1] rsync  version 2.5.6  protocol version 26.  Capabilities: 64-bit 
files, socketpairs, hard links, symlinks, batchfiles, no IPv6, 64-bit 
system inums, 64-bit internal inums

[2] rsync  version 2.5.6  protocol version 26.  Capabilities: 64-bit 
files, socketpairs, hard links, symlinks, batchfiles, IPv6, 64-bit 
system inums, 64-bit internal inums