On Sat, Jul 08, 2000 at 02:40:22AM +1000, Mike Benoit wrote:
> I'm attempting to use Rsync (2.4.3) to update files between a Linux server,
> and a Linux client with a mounted vfat partition (/c). I've heard about the
> problem where windows mtime's arn't 100% accurate to the second, and
> noticed that myself, but I'm not totally sure if vfat in linux mimics that
> problem or not. I highly doubt it though.
>
> The problem is this. If I run rsync with the following command:
>
> rsync -rptS --timeout=240 --stats --delete --exclude-from=exclude.lst
> [EMAIL PROTECTED]::sync/ /c/
>
> It takes approx. 18minutes on a Celeron 333a 64mb ram client, same only
> 128mb ram server to complete the task. When using full verbose (-vvvv ) I
> notice that rsync is calculating checksums for virtually every file if not
> every file. (25,000 files, 1.5 gb's about) If I run the above line twice in
> a row, one right after another (obviously no files have changed) it _still_
> calculates checksums.
>
> The weird part is this.
>
> rsync -rptS --timeout=240 --stats --delete --exclude-from=exclude.lst
> [EMAIL PROTECTED]::sync/windows /c/windows
>
> If I run the above line, (just update the windows directory) the first time
> it runs, all the checksums are calculated, (240megs or so) If I run it
> again, immediately after, its completed in about 5seconds, no checksums are
> calculated at all. (this is how it should be, correct?)
>
> So why when I try to update the entire exported directory (or share, which
> ever you want to call it?) at once (::sync/ /c/), it calculates the
> checksums for every file, every time its run regardless, but if I just do
> one directory at a time(::/sync/windows /c/windows/), it seems to work the
> way it should? Thanks.
Were the things in /sync/windows originally copied from a VFAT partition
and the things in a lot of the rest of the directories originally generated
on Unix? I would assume that everything generated on Windows would have
write times that are only even numbers (since its granularity is 2 seconds)
and that things written to on Unix would have a 50% chance of having an
odd timestamp and thus rsync would think they didn't match.
If --size-only is allowing rsync to accept everything and not calculate
checksums, it's gog to be a timestamp problem. Somebody should try
modifying rsync to accept any timestamp +-1 second as a match. I don't
even know if it's worth making it an option or if it should just always do
that. If VFAT always truncates the second, you wouldn't even need to
check for +1, just minus 1. Or just compare (t1 & ~1) == (t2 & ~1) or
(t1 >> 1) == (t2 >> 1).
- Dave Dykstra
