Windows and default --modify-window=0

[jw schultz]

On Thu, Jan 09, 2003 at 10:36:33AM -0600, Dave Dykstra wrote:
> On Thu, Jan 09, 2003 at 01:02:29PM +0100, Lapo Luchini wrote:
> > Uhm... rsync developers: what do you think about changing the default 
> > modify-window in the Cygwin platform?
> > It seems to me that many problems people have are just because of the 
> > granularity of timestamp.
> > Maybe changing the default could be the best choice. That would be 
> > documented in the "man" and in my release announcement on 
> > cygwni-annouce, of course.
> > 
> > Just an idea, maybe it's bad 0=)
> 
> 
> As I understand it, --modify-window=2 is needed whenever you're copying
> between a Windows filesystem (maybe only specific types, does anybody
> know??) and a Unix filesystem.  Just because you're running on Cygwin,
> that doesn't necessarily mean you're doing that although the risk of a
> file modification time legitimately being off by a few seconds is pretty
> low in the cases where it isn't really needed.  (Conversely, on Linux
> you may be accessing a Windows filesystem directly but I realize you're
> not talking about that situation).
> 
> The main problem is that if Cygwin always added the --modify-window=2
> option to parameters it passes to the remote side it would fail if it were
> talking to a release of rsync that is too old to recognize the option.
> If it could be done on the cygwin side only, without passing the parameter
> to the remote side, it might not be so bad.  I guess that would mean it
> would work only when receiving files from a Unix system and not when
> sending to them.  The surprise factor on that may be too much to make
> it worthwhile.

The 2 second timestamp resolution only applies to some
windows filesystems.  I think NTFS has timestamp resolution
in the milliseconds (unlrelated to precision).  It should
only become an issue when the windows filesystem is the
destination.

The timestamp comparisons are actually done on the
destination.  Since you only need the --modify-window for
a *ix->windows transfer the it might be possible to HACK it
on the cygwin end.  Further examination shows that it is
already hacked in options.c for win32:  
| #ifdef _WIN32
| int modify_window=2;
| #else
| int modify_window=0;
| #endif
perhaps something just needs to be added to the #ifdef.


PS.  If i'm reading things correctly you only need a
modify_window of 1 since it is a <= test.

-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw at pegasys.ws

		Remember Cernan and Schmitt