Post a reply

Before posting, please read how to report bug or request support effectively.

Bug reports without an attached log file are usually useless.

Add an Attachment

If you do not want to add an Attachment to your Post, please leave the Fields blank.

(maximum 10 MB; please compress large files; only common media, archive, text and programming file formats are allowed)


Topic review


Sorry, I got confused.

So only the screenshot of the panels and a corresponding complete session log file.

Scripting session log file? I'm not using scripting. Or do you mean something else?

The scripting should use the same timestamps as the GUI.
Can you attach a screenshot of the panels, corresponding complete (!) session log file and complete scripting session log file?

Okay, that's strange, because the local file should have been 5 minutes newer than the remote version. This was showing correctly in the file panels too. Is there a timezone issue on the server side?

Mirror mode might be a viable workaround, but it would be nice to know why the timestamps weren't working for me on this occasion.

You are using local-to-remote synchronization.

The local (source) file orderConfirmation.asp is older than the remote (target) file.

So clearly when using "time" criteria only, the file is not updated.
With "time or size" criteria, it's not that obvious. Because it not really "newer or different-size", but "newer or (same-age but different-size)". So again, the file is not updated, because it's older.

If you want to update file on any difference, not only when the file is newer, use Mirror files mode.

I'm uploading a log file. I removed the 'session upkeep' lines to make it easier to read.

I enabled debug level 2 in the logging window and then performed 3 synchronizations:

The first one used both criteria and returned no results.
The second used modification date only and returned no results.
The third one used file size only, and returned one result. I then synchronized the file.

This file, orderConfirmation.asp, has a different file size AND a different modification date, so it should have shown for all three synchronizations.

Re: Bug with Comparison Criteria

WinSCP is doing OR.

Please attach a full log file showing the problem (using the latest version of WinSCP). Note a name of a file that should be considered different and was not.

To generate log file, enable logging, log in to your server and do the operation and only the operation that causes the error. Submit the log with your post as an attachment. Note that passwords and passphrases not stored in the log. You may want to remove other data you consider sensitive though, such as host names, IP addresses, account names or file names (unless they are relevant to the problem). If you do not want to post the log publicly, you can mark the attachment as private.

Bug with Comparison Criteria

Hi again!

This has happened to me a few times in the last few months. It's still present in 5.7.2 but I'm not sure when it first manifested itself.

By default, I choose to compare by both modification date and file size when doing a sync. However, I've found occasions when one or two files haven't been synced when they should have been. When I have detected this, I have experimented by just using file size as my comparison criteria, and only then did it detect the difference.

I'm wondering if the comparison criteria is doing a logical AND instead of a logical OR for these differences. I think it's implicit that if you have moth criteria checked, WinSCP should consider a file as different if either the timestamp OR file size is different, not both.

Can you confirm this observation?