checksum-xattr.diff [CVS update: rsync/patches]

[Matt McCutchen]

On 7/2/07, foner-rsync at media.mit.edu <foner-rsync at media.mit.edu> wrote:
> Unreliable.  If you sync up at the beginning of a run, and then the
> remote system executes a large clock step (e.g., because it's not
> running NTP or it's misconfigured, or it is but NTP has bailed due to
> excessive drift from hardware issues or a bogus driftfile (both of
> which I've seen*), then "now" might glitch by a second (or more),
> which is enough to break your idea of what "now" means---even a
> smaller glitch can lead to races based on whose clock ticks first.
> Sure, it's a low-probability event, but then, with low probability,
> you have some file that isn't getting updated, which can lead to all
> kinds of mysterious bugs, etc...

The technique Wayne and I are discussing assumes only that the clock
on *each side* never steps backwards.  It compares the current mtime
and ctime on each side to the previous mtime and ctime on that side as
recorded in the cache.  Clock synchronization between the two sides is
irrelevant.

It is true that if either side's clock steps backwards, that side
could be fooled into thinking a file hasn't changed from the cache
when it really has.  There's very little we can do about that except
tell the sysadmin to delete all the caches when he/she sets the clock
backwards.

> Seems to me the only way around this would be to do the touch before
> -every- file you handle, which doubles the amount of statting going
> on, etc.  And there are probably still timing windows there.

I don't understand this concern.  If you'd like a more formal proof
that the technique never misses a modification assuming each side's
clock runs forward (actually, just each filesystem's clock), I would
be happy to provide one.

Matt