rsync - Jul 2006 - rsync transferring identical files

Hi all,
I have set up a backup system which is syncing files between a linux  
based file server and a remote server on the internet.
After doing an initial rsync with the following command:

rsync -a --delete --numeric-ids --relative --delete-excluded     -- 
exclude=*__software* --exclude=*.AppleDB* --exclude=*.DS_Store*     -- 
exclude=*:2e* --exclude=*.AppleDesktop* --exclude=*.AppleDouble*    -- 
rsh=/usr/bin/ssh backup@myserver.com:/storage/files     /backup/ 
location/

and letting the process run for about 5 days, I changed a few of the  
files and ran it again and now it seems to be transferring all of the  
files again, even the ones that haven't been changed. The servers are  
in different timezones, but from what I have read this shouldn't  
matter. If I run the command again and let it transfer a few files,  
then stop it and run it again - it seems to "fix" the problem for  
those files, even though they have identical timestamps and sizes as  
before.

Is there anything I can do to avoid having to run this again for a week?

All the best,

Ben

On Mon, Jul 10, 2006 at 09:05:30PM +0100, Ben Pirt
wrote:
> I changed a few of the files and ran it again and now it seems to be
> transferring all of the files again, even the ones that haven't been
> changed.
Are you sure you got exactly the same command?  Something like an added
or removed trailing slash or an added or removed --relative option could
mean that you're unintentionally copying files to a new location.

The best way to check what rsync thinks it is doing is to use the -i
(--itemize) option.  This will show if rsync is creating new files
(which are displayed with all + chars), OR, if it is updating a file,
exactly what rsync thinks is different about the file (it will also
show non-transfer file adjustments, so look for the files prefixed
with a > or a < if you want to know what files are being transferred).
You'll see a 't' (time) in the itemized display if rsync thinks the
timestamps are different.
> The servers are in different timezones, but from what I have read
> this shouldn't matter.
Right.  There are cases where a filesystem that stores files with the
local time instead of GMT can cause a problem, but that shouldn't cause
a problem at this time of year.  There are also some file systems that
can't hold an odd time-stamp value (e.g. FAT), so if you're copying to
such a filesystem, you should use --modify-window=1 to have it treat
such off-by-one timestamps as the same value.

..wayne..