Synchronize skips file

I am facing an issue which I cannot understand, maybe someone can explain it or even provide hints to solve it.
I am using a script to synchronize 2 directories. The transfer is done by FTP. Usually, the script works.
Now, the transfer of a particularly big file failed due to some connection issues. In this post, I shall not dive into the questions as to why the transfer was not resumed. The important part is that I have now my source folder with the original file (appr. 130 GByte) and the destination folder with the half-transferred file (appr. 67 GByte). When I re-run my script, the synchronize command does see both files, but it then says "Nothing to synchronize".
The script looks like this:The log file shows these lines:When I try synchronization from the GUI, the result is the same.
Why is the file file skipped, even though the file size is different, and the file size should be checked as a criteria for transfer?

See documentation:
https://winscp.net/eng/docs/ui_synchronize#criteria

When both options are checked, Modification time has higher priority. As a consequence, in the default Synchronize files synchronization mode, a file is not considered updated, despite having different size, if the source file is older than the destination file.

So you may want to switch to the mirror mode:
https://winscp.net/eng/docs/task_synchronize_full#mode

Indeed, the documentation says so. I had not considered it necessary to follow the link "Comparison criteria" because it seemed clear that both the file size and the date would be checked - not that one of them would overrule the other.
It is not obvious to me why there is such a precedence, but I take it that you have solid reasons for this decision.
I will try adding the "-mirror" switch and see what happens.
Torsten

So, I have tried it out, and the -mirror switch does the job.
Thank you for you swift response, Martin!

Unfortunately, the working script brings me back to the problem which made it necessary to "re-run" the synchronization in the first place.
When I ran the script again today, the transfer broke at more or less the same point as it did last time: After 2 hours and 10 minutes, out of the blue. I find that a strange coincidence.
The target FTP server is a NAS which can doubtlessly handle these files, and so does the network connection. As a matter of fact, I have uploaded many files of this size before.
I am running the script a third time now, and if it fails again, I will run a manual upload from the WinSCP user interface or even with Filezilla to locate the point of failure. I will share the results here.

As promised, I come back here.
The connection breaking after 2 hrs and 10 min seems to be reproducible. I will open a new thread for this issue.
But the original issue (skipped files) has been solved. Thanx!
/Torsten