Unexpected problem: DirsSync-1.3-rc3 - directories synchronizer
Christos TZOTZIOY Georgiou
tzot at sil-tec.gr
Mon Nov 3 19:36:16 EST 2003
More information about the Python-list mailing list
Mon Nov 3 19:36:16 EST 2003
- Previous message (by thread): Unexpected problem: DirsSync-1.3-rc3 - directories synchronizer
- Next message (by thread): ANN: SQLObject 0.5
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Sat, 1 Nov 2003 21:39:47 +0100, rumours say that "GerritM" <gmuller at worldonline.nl> might have written: >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? -- TZOTZIOY, I speak England very best, Ils sont fous ces Redmontains! --Harddix
- Previous message (by thread): Unexpected problem: DirsSync-1.3-rc3 - directories synchronizer
- Next message (by thread): ANN: SQLObject 0.5
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list