On 7/2/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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 -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
