This issue has been added to the tracker:
Issue 249 – Ignore less than 2 seconds timestamp difference when synchronizing.

I have sent you a debug version.

I'll send you a debug version soon.

dtgriscom wrote:

However, looking on the Mac (both with command line tools and the Finder), the time on the remote file is one hour earlier than shown in the WinSCP remote pane. (Both machines are set to EDT.)

Please read documentation:
<link removed by admin as the functionality is deprecated>

The WinXP disk uses NTFS.

As a test, I copied the suspect file into a test directory on the Windows machine, created a test directory on the Mac machine (on the FAT32 drive), and copied the file over with WinSCP. I then used the Cygwin tool "touch" to update the time of the local file to "now", and then repeatedly tried synchronizing with WinSCP. After a "touch", of course WinSCP would declare the files different and copy the local file to the remote, ending up with the remote file the same as the remote. However, if I'd happened to "touch" the local file so that its last digit was odd then a repeated synchronize would show it again, and again, and again; an even last digit would only need to be synchronized once.

On my most recent try, the local timestamp given by WinSCP is 6/6/2008 1:22:35PM; the remote timestamp is 6/6/2008 1:22;34PM.

There's something else weird going on. As I've said, in WinSCP the local and remote files all have the same time stamps, except for those mysterious files where the local seconds are odd and the remote seconds are even. And, the WinSCP time stamp for the local file matches that given by both Windows and the Cygwin command-line tools. However, looking on the Mac (both with command line tools and the Finder), the time on the remote file is one hour earlier than shown in the WinSCP remote pane. (Both machines are set to EDT.)

Is there anything else you'd like me to look at?

Thanks,
Dan

dtgriscom wrote:

I'm using WinSCP 4.0.6.358, and I've found that if the local file has an odd number of seconds then it is forever re-synchronized with the remote file (which always has an even number of seconds).

I'm not able to reproduce the problem. WinSCP should ignore one-second difference in the timestamp.
What file system are you using locally? Can you provide me example of timestamps, in case it is specific to some (both local and remote, including date).

I'm using WinSCP 4.0.6.358, and I've found that if the local file has an odd number of seconds then it is forever re-synchronized with the remote file (which always has an even number of seconds).

I've just tried again, and a Synchronize command yields 345 files. I didn't scan them all, but the first ten local files has odd seconds, and the remote files have even seconds, with all sizes and the rest of the times the same.

I just tried re-syncronizing a subdirectory where the Synchronization checklist file lists 20 files, again all with odd local and even remote seconds. I then repeated and got the same 20 files. Third time the same list is shown, and then copied.

Settings:

• Direction: Remote [again, an OS X machine with a DOS-formatted volume]
  
• Mode: Synchronize files
  
• Synchronization options chosen: Delete files, Preview changes
  
• Comparison criteria: Mod time and file size
  

Any ideas?

Difference of 1 second is ignored by WinSCP since version 3.7.5 (for the reason you refer to).

For DST difference, please read documentation.

I'm using WinSCP to synchronize with a Mac running OS X 10.5. Plugged into the Mac is a FAT-formatted drive. Problem: this rounds all timestamps to the nearest even second. This means that every time I sync anything that has a locally odd last time digit will get synched again.

There are also situations where the timestamp will be an hour off (due to daylight savings issues), although the problem is cured by the first transfer.

Suggestion: add a "Time Slop" (or something like that) preference, such that time differences no greater than the slop are considered to be zero. In the above case, I'd set a Time Slop of 1 second.