Synchronize redownloads all files at each run, even existing/up to date ones

Hi,

Running into some issues with the synchronize feature. Originally I am using scripting, but I checked the problematic behaviour also appears using the UI.

Intention is to regularly synchronize files from a remote host to a local folder, using
a filemask to only synchronize files from "today".

Basically each time I run the command, all the files that are included in the filemask are redownloaded, disregarding if they are already present in the destination folder, disregarding if I select the timestamp or filesize criteria.

Command Run

script.winscp

See attached files for the WinSCP log with all the configuration details + the local list of files on disk when the command was ran.
You will have to trust me on the fact that the timestamps (hour, minutes AND seconds) match between the two as far as I can tell, and taking into account timezone differences between local PC (GMT+2), and remote server (UTC).

Using the UI, WinSCP showed the same behaviour and proposed to synchronize (as in download) again each file, despite some of the files being there already. Strangely enough, in "Synchronize timestamps" mode, the UI indicated "No Differences found".

So would you give us names of some files that should not have been transferred, but were?

I tried to create a simpler example, not using scripting but via plain WinSCP UI.

In the attached screenshot, you will see that the synchronize function proposes me by default to sync the "202006012115...gz" file from remote to local, whereas it is alread present locally, with the same date and the same size. I woudl expect this file to be unchecked by default, while the other two remote files to be indeed selected by default, as they are not present locally.
PS: I've also added the options used for synchronize, just in case.

But I need the session log. Strange is that there's no time and size of the local file in the checklist window.

After reviewing the log file more carefully, I understood my problems were caused by an incorrect file mask. Now I'm not sure why my "file mask logic" was wrong, but that's for another topic.