rsync - Mar 2004 - Odd behavior with rsync/ssh/--delete

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@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

On Sun, Mar 21, 2004 at 09:51:18PM -0700, Peter Wargo
wrote:
> 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.
Does the destination system have any mounted filesystems inside the
single mount from the source system?  Try dropping the -x and using one
or more --exclude directives for the mount point(s) that should be
skipped.

Can you reproduce the problem with a smaller file set?  Try transferring
just one home dir that had a problem and see if that still fails.  Use
-vvvv so you can see the file list from both sides of the transfer
(which is why I recommend trying this with a smaller file set -- it
generates a lot of output).  There will be two dumps of the file list
from the receiving side.  The first is the list it received from the
sender, and the second is the list that it created to look for
deletions.  Look for any unexpected differences between those two lists.
Rsync will delete anything that is extra in the second list, even if it
is just out of order (which it shouldn't be).

..wayne..