Well, we actually run Rsync in Linux, but pull the files from a Linux
server, to a vfat mounted partition on each client machine. I know if I run
rsync twice in a row, without rebooting or doing anything, it takes the
same amount of time, about 25mins. It only writes very small amounts of
data, but it checksums practically every file, which is what takes the time
I guess. So something either isn't being updated properly or, like you
said, the timestamps are off by 6 seconds.
rsync -rtS --size-only --timeout=240 --stats --exclude-from=exclude.lst
[EMAIL PROTECTED]::sync/ /c/
Thats the command we use, so we are attempting to preserve timestamps, I
haven't looked too deeply in to this yet though.
At 12:57 PM 7/3/2000 -0500, you wrote:
>On Tue, Jul 04, 2000 at 03:41:22AM +1000, Mike Benoit wrote:
>...
> > We update about 1.5gb of data each reboot, currently we use the
> --size-only
> > switch to speed things up, with that switch the entire process (from
> > rebooting Windows, to being back in Windows) is about 5 minutes. If we
> take
> > that switch off, its unfortunately about 25mins.
>...
>
>It sounds like it is not getting a match on the timestamps if --size-only
>makes that huge of a difference. Are timestamps being copied ('-t', implied
>by '-a')?
>
>I remember hearing something about a mismatch in the granularity of
>timestamps on Unix vs. Windows, where Unix goes down to the second and
>Windows is down to the every 6 seconds or something like that. So if the
>master is on Unix and the copy is on Windows it may never be able to get a
>match. If that's the problem, maybe a Windows version of rsync needs to
>accept anything within six seconds as a match.
>
>- Dave Dykstra
