SCP Synchronize Local always copies, remote never does

I'm trying to sync directories via script using WinSCP 5.7.1 and SCP protocol between a Win7 SP1 local and a VMware vSphere host remote (running some variant of Linux - BusyBox v1.20.2??? See logs). I started with either local or remote dir empty to force the first sync to copy all, but then immediately repeat the synchronize call, and then make the reverse synchronize call (if first was sync local, then do sync remote). In all cases after the first sync copies all (as expected), sync local ALWAYS copies all AGAIN, and sync remote says "nothing to synchronize", although from the logs it thinks the remote files are more recent). It appears that the remote directory listings are in GMT and local listings are in local (CST) time, and this is causing the problem.

Is there a way I can tell it what time offset to use to compensate?

Also note that the remote "--full-time" parameter for the ls command does not appear to be supported by BusyBox v1.20.2, but it still gets (what I think are) valid results.

You need to compensate this difference:

. 2015-04-07 09:58:08.068 vmware-10.log;-;165277;2014-12-03T22:47:00.000Z;"root" [0];"root" [0];rw-r--r--;0

. 2015-04-07 09:58:08.271 File: '/vmfs/volumes/datastore1/test/vmware-10.log' [2014-12-03T16:47:09.000Z] [165277]

So -6 should help.

The question is: how do I tell >> WinSCP << to do this compensation FOR me?

Your answer implies that I would have to do a directory listing and make that compensation MANUALLY for each file, making the Synchronize method useless. Even worse, I noticed that files that were last modified in, say, December (before the spring time change) were only >> 5 << hours different, not 6.

I was hoping that WinSCP would be able to handle all this for me.

You can configure the offset here:
https://winscp.net/eng/docs/ui_login_environment

Though you better use SFTP, as it should not have the problem.

I tried all possible combinations of time offset and DST compensation in the GUI and none of them gets the timestamps correct (see below). I have listed three examples files: one dated before the Fall time change, one just after the Fall time change, and one current file (after the Spring time change). Given the mismatches, the Synchronize command keeps copying the files every time.

Any suggestions?


Time offset -5 hrs, Adjust remote timestamp to local conventions
Local Remote
vmware.log 12/23/14 11:03:55 AM 12/12/14 12:03 PM Remote ahead 1 hr
vmware-5.log 10/21/14 4:20:15 PM 10/21/14 4:20 PM Correct
vmware-6.log 4/20/15 12:30:27 PM 4/20/15 12:30 PM Correct


Time offset -5 hrs, Adjust remote with DST
Local Remote
vmware.log 12/23/14 11:03:55 AM 12/12/14 12:03 PM Remote ahead 1 hr
vmware-5.log 10/21/14 4:20:15 PM 10/21/14 3:20 PM Remote behind 1 hr
vmware-6.log 4/20/15 12:30:27 PM 4/20/15 11:30 AM Remote behind 1 hr


Time offset -6 hrs, Adjust remote timestamp to local conventions
Local Remote
vmware.log 12/23/14 11:03:55 AM 12/12/14 11:03 AM Correct
vmware-5.log 10/21/14 4:20:15 PM 10/21/14 3:20 PM Remote behind 1 hr
vmware-6.log 4/20/15 12:30:27 PM 4/20/15 11:30 AM Remote behind 1 hr


Time offset -6 hrs, Adjust remote with DST
Local Remote
vmware.log 12/23/14 11:03:55 AM 12/12/14 11:03 AM Correct
vmware-5.log 10/21/14 4:20:15 PM 10/21/14 2:20 PM Remote behind 2 hrs
vmware-6.log 4/20/15 12:30:27 PM 4/20/15 10:30 AM Remote behind 2 hrs

Any suggestions?

Did you try SFTP?

Please understand that SCP protocol is obsolete and its implementations are inconsistent, so we do not really aim to improve/support it much.

Sorry - I didn't know that SCP was obsolete. SFTP works fine using the Synchronize method. (Sigh. I spent hours trying to recreate my own Synchronize the hard way.)

Thanks for your help!!

Bill Cumming

Thanks for your feedback.