Cygwin issues: modify-window and hangs

[Dave Dykstra]

On Fri, Jan 24, 2003 at 05:18:07PM -0600, Dave Dykstra wrote:
> I had a friend run some Cygwin tests and we found that --modify-window=1
> works just as well as --modify-window=2 on FAT filesystems to copy files
> from Unix and detect the difference in granularity.  FAT filesystems always
> have timestamps that have an even number of seconds.  On the other hand,
> NTFS filesystems can store the modification time down to the second,
> whereas previously people on this mailing list thought it was just like
> FAT for modification time.  Nevertheless, I decided to change the default
> value for --modify-window to 1 on Cygwin rather than 0, under the thinking
> that even on NTFS filesystems it wouldn't do any harm because it's highly
> unlikely that any individual file will be modified again within one second
> after it is copied by rsync.

This modify-window default of 1 has been causing some trouble on the rsync
test suite on the Cygwin test machine on build.samba.org.  The problem
is that some files get created and immediately copied within one second,
and then the rsync code that implements '-p' checks to see if the copied
file's time is within one second before deciding whether or not to change it.
The test machine is presumably using an NTFS filesystem so it has one
second granuarlity.   Last night I considered 4 possible solutions:
    1. Change the test suite to always wait 2 seconds before copying, at
	the beginning of the "checkit" function.
    2. Change the test suite to always pass --modify-window=0 to rsync by
	including it in the $RSYNC variable in testsuite/rsync.fns.
    3. Change the set_perms() function in rsync.c to check for exact time
	rather than calling cmp_modtime.
    4. Back out the default of --modify-window=1 on cygwin and go back to
	a default of 0.

I implemented solution 1, but I'm not very comfortable with it because
it slows the tests on all platforms. I'm now leaning toward solution 3.
Discussion?

- Dave