[Unison-hackers] Windows Daylight Savings Quirk

[Kian Win Ong]

Hi,

This is a cross-post from the user list.

I am using Unison 2.9.1 (on both ends) to synchronize between a Windows
and Linux host. A Windows quirk / bug causes Unison to mistakenly think
that file modtimes have changed, whenever we cross over into daylight
savings. Here is how the problem can be replicated.

On a Windows NTFS partition (I am using Windows XP)

%> echo > may
%> dir
    05/11/2005  12:07 PM                13 may

%> date 01/11/2005
%> echo > jan
%> dir
    01/11/2005  12:07 PM                13 jan
    05/11/2005  11:07 AM                13 may

We have created two files, one in Jan before daylights savings, and one
in May after. (Notice that when we switch the time to Jan, the timestamp
of the May file changes by an hour. This is really a presentation bug -
rest assured that internally the actual timestamp is stored correctly.)

At this point, we are in January.

%> unison test
    [unison successfully copies the files to my linux machine]
%> unison test
    Nothing to do: replicas have not been changed since last sync.

On the Linux machine,

%> ls
    13 2005-01-11 12:07 jan
    13 2005-05-11 11:07 may

Unison faithfully propagates the Windows bug for the timestamp onto
Linux. No issue: garbage in garbage out. Let us fast forward to May to
see the real problem.

%> date 05/11/2005
%> dir
    01/11/2005  01:07 PM                13 jan
    05/11/2005  12:07 PM                13 may
%> unison test
    local          laksa
    props    ---->            jan
    props    ---->            may
    Proceed with propagating changes: N

Since Windows itself displays the dates differently when we cross
daylights savings, Unison picks up this change. Consequently, the
timestamps of all files need to be unnecessarily re-synchronized. I
suspect that this is what cause the fast-checks to fail as well.

A possible workaround for the user is to turn off daylight savings
adjustment in Windows every time before he runs Unison. If we do that
for the running example,

Windows:

Clock (System tray) -> Time Zone
[ ] Automatically adjust clock for daylight saving changes
%> unison test
    local          laksa
    props    ---->            may
    Proceed with propagating changes: Y

Linux:

%> ls
    13 2005-01-11 12:07 jan
    13 2005-05-11 12:07 may

We find that Unison picks up the correct timestamps (in spite of
Windows' bug), once daylight savings adjustment is turned off.

While this is an acceptable workaround, it is a little inconvenient to
have to toggle settings everytime synchronization is required. Moreover,
I am unaware of any programmatic way to turn off daylight savings, so
this precludes scheduling synchronization in a fully automated setting.

More details of the Windows daylight savings time bug can be found at
http://www.codeproject.com/datetime/dstbugs.asp?df=100&forumid=2218&exp=0&select=229121
http://support.microsoft.com/kb/q158588/
http://support.microsoft.com/kb/q129574/

The executive summary is that, at least for NTFS volumes, the file
modtime has to be retrieved via the Windows API call GetFileTime()
instead of the C library stat().

I am aware that 2.10.2 is out, but from the changelogs and mailing
lists, it seems that this issue still applies to the latest version.
Will be great if someone running 2.10.2 on a pair of Linux and
Windows/NTFS machines can verify that the presence of the problem.

Are Windows API calls permitted in Ocaml? If not, those of us
unfortunate enough to use Windows may have to live with the sub-optimal
workaround...

Regards,
Kian Win