Keep remote directory up to date doesn't work when the remote server time is different

I'm working with a server which is one hour ahead of my local time.

When I try to keep the remote directory up to date, any file which is uploaded gets a timestamp 1 hour in the future.

This means that after the first upload, synchronization doesn't work for the next hour. WinSCP reports a change in the local directory but doesn't upload any files. I end up having to upload files manually.

Why does WinSCP check the time on the remote server when keeping remote up to date? Surely the only thing that matters is that there was a file change on the local machine. The remote timestamp should be ignored.

Is there anything I can do to force uploading of the files when they change?

PS: Thanks for making this great program.

fungus wrote:

I'm working with a server which is one hour ahead of my local time.

When I try to keep the remote directory up to date, any file which is uploaded gets a timestamp 1 hour in the future.

That should not happen.

Please attach a full session log file showing the problem (using the latest version of WinSCP).

OK, here's a log file.

I started the synchronisation then modified the file twice.

The first time: The file was uploaded correctly (I hadn't modified it since yesterday).

The second time: WinSCP says changes were detected, no file is uploaded.

Your FTP server does not support the MDTM command. So WinSCP cannot update the file timestamp.

martin wrote:

Your FTP server does not support the MDTM command. So WinSCP cannot update the file timestamp.

> 2017-02-19 22:16:32.518 MDTM 20170219211631 Admin.php
< 2017-02-19 22:16:32.549 550 Could not set file modification time.

So? That shouldn't cause WinSCP to stop uploading.

The only thing that matters when using "keep remote director up to date" is when the file is modified on the local machine. The remote timestamp should be completely ignored for this function.

(or at least, I should have the option to ignore it. Do I? I can't find an option like that)

fungus wrote:

So? That shouldn't cause WinSCP to stop uploading.

But that's not, how it works. Of course, it can be changed not to require an update of the remote file timestamp. But your problem is very rare.

martin wrote:

fungus wrote:

So? That shouldn't cause WinSCP to stop uploading.

But that's not, how it works. Of course, it can be changed not to require an update of the remote file timestamp. But your problem is very rare.

I don't want to update the remote timestamp. I don't care at all about the remote timestamp.

What I want is for WinSCP to upload a file whenever I change it on the local machine.

It's supposed to do that but it doesn't.


PS: This server is on a large Spanish ISP - "Arsys".

fungus wrote:

What I want is for WinSCP to upload a file whenever I change it on the local machine.

It's supposed to do that but it doesn't.

Sorry, but this is just playing with words. No it's not supposed to do that. WinSCP does, what it does. I'm sorry it does not work for you. But I'm probably not going to reimplement whole functionality only because your server is limited.

martin wrote:

fungus wrote:

What I want is for WinSCP to upload a file whenever I change it on the local machine.

It's supposed to do that but it doesn't.

Sorry, but this is just playing with words. No it's not supposed to do that. WinSCP does, what it does. I'm sorry it does not work for you. But I'm probably not going to reimplement whole functionality only because your server is limited.

Perhaps this thread should start over at the "That should not happen" because the user does not appear to understand why it Should Not Happen with SFTP?

Answer: because the underlying SSH protocol is supposed to be using UTC in order to have the client and server report timestamps on the same basis. Client translates filesystem timestamps to UTC. Server does same.

However, SFTP implementations appear to not always do UTC translations correctly with an added DST consideration. It also appears one way to check if this is the case is to compare timestamps reported with a sftp "ls -l" to timestamps reported by a sftp "ls -ln" ('n' to cause numeric/raw values to be used).

So rather than leave this thread on a rather sour note, perhaps manually checking the output of "ls -l" and "ls -ln" with SFTP and report back?