Unexpected problem: DirsSync-1.3-rc3 - directories synchronizer

[GerritM]

I downloaded and tried the recently announced dirsync program. It looks
nice, but...

I have two presumably identical directories: one at home and one at work. I
keep them synchronized by means of zipping changed files and extracting them
at the other side. When comparing both directories by means of this nice
program I discovered that all files differ, with an mtime difference of
exactly 1 hour. I am working on a windows 98 machine at home, Windows 2000
at work. Winzip 8.0. Somewhere in the chain a time coversion takes place,
errorneously...

Most suspect for me is the fileserver at work, since I try to compare a
recent snapshot made at work with my directory at home. Careful examination
of a zipfile created before the wintertime started and a zipfile created
after this date shows a one hour difference for files before the critical
date.All zipfiles were made at work (windows 2000, data residing on a
fileserver; make unknown, presumably on Linux/Unix).

Anyone seen comparable problems? This effect is rather disastrous if you use
timestamps for synchronization :-(

regards Gerrit

 

[Christos TZOTZIOY Georgiou]

I downloaded and tried the recently announced dirsync program. It looks
nice, but...

I have two presumably identical directories: one at home and one at work. I
keep them synchronized by means of zipping changed files and extracting them
at the other side. When comparing both directories by means of this nice
program I discovered that all files differ, with an mtime difference of
exactly 1 hour. I am working on a windows 98 machine at home, Windows 2000
at work. Winzip 8.0. Somewhere in the chain a time coversion takes place,
errorneously...

Most suspect for me is the fileserver at work, since I try to compare a
recent snapshot made at work with my directory at home. Careful examination
of a zipfile created before the wintertime started and a zipfile created
after this date shows a one hour difference for files before the critical
date.All zipfiles were made at work (windows 2000, data residing on a
fileserver; make unknown, presumably on Linux/Unix).

Anyone seen comparable problems? This effect is rather disastrous if you use
timestamps for synchronization :-(

regards Gerrit

I presume you also live in a Daylight Savings Time timezone?

Yes, welcome to the beautiful world of Windows timestamps... windows
system calls that return file timestamps do not take into account that a
file changed during summer time had +1 hour difference from UTC compared
to a file changed after the end of summer time, and they assume constant
time difference throughout the year. If you don't believe me, change
the date/time to a little before time changes in your location, create a
file, check its timestamp, wait a little till the time changes, then
check its timestamp again.

I believe POSIX compatibility did not specifically include honesty in
the requirements for the return values of system calls... or even
cluefulness on behalf of the POSIX-compatible-OS-wannabe-developers.

The only thing I could do in my own directory sync code (mind you, using
sets.Set helps a lot in finding differences!) was to optionally add 1
hour to the returned timestamp if the timestamp falls between last
Sunday of March, 03:00 localtime and last Sunday of October, 03:00
localtime. I also carefully avoid to touch files in the involved
computer when the time is between one hour minus and one hour plus the
time-change times for various precautionary reasons

How many times can I use the word time in a sentence?