Waruwaru wrote:

Okay... I must google what is a trace file and found this https://winscp.net/eng/docs/debugging
I use winscp 5.14.2 (Dev Build 8964 2018-11-20)

No. In September and November, on four different occasions, I've sent you a debug version of WinSCP to your email address. I need you to use that one. I'm sending you one more copy now.

Okay... I must google what is a trace file and found this https://winscp.net/eng/docs/debugging
I use winscp 5.14.2 (Dev Build 8964 2018-11-20)

@Quick Instructions

Windows Explorer will open with the trace file selected.

After closing winscp, its not open explorer. And that's a good thing.

@Advanced Instructions

If the Windows Explorer does not open with the trace file, locate it manually in the same folder, where you have extracted the winscp.exe executable to. The trace file has a name like winscpXXXXtrace.log.

In the folder with winscp there is no file named winscp*.log. This folder have write access. Its updated winscp.ini and its startet with administrator privileges.

Waruwaru wrote:

Here is no issue. This issue exists only on very long time synchronization.

I know, but I need it for comparison.

Which level I must set for enable session logging? Normal, Debug 1 or Debug 2?

I was asking for trace logs from the debug version, I've sent you. Not for session log file.

1) Working transfer/synchronization of one of those files (by working with that one file only).

Here is no issue. This issue exists only on very long time synchronization.

2) Failing transfer/synchronization (by working with large [but smallest possible] set of files).

Which level I must set for enable session logging? Normal, Debug 1 or Debug 2?

Waruwaru wrote:

I have synchronize a very small part of last sync (two days ago; folder have 129.074 files, 25.606 folders and size of 2,25 GB), with the same dev build. This time its show me the wrong files last time created to replace with correct file names:
...

OK, so can you send me a trace files for
1) Working transfer/synchronization of one of those files (by working with that one file only).
2) Failing transfer/synchronization (by working with large [but smallest possible] set of files).

Hint: above was already the dev winscp version.
Okay, that is strange; I make the steps you wish and there was no issue. Not with japanese filename and not with german umlauts, not for copy and not for synchronize. But in my very huge synchronize it was for both. I estimate that there is maybe a memory issue for long running synchronize?

I have synchronize a very small part of last sync (two days ago; folder have 129.074 files, 25.606 folders and size of 2,25 GB), with the same dev build. This time its show me the wrong files last time created to replace with correct file names.

OK, so can you please use the debug built, I've sent you for the "freeze" problem. And with that build:
1) download the file with Japanese name.
2) synchronize a folder that contains only the one file with Japanese name to an empty local folder.
And send me a trace log file and a session log file for that test.

Here a first test with winscp dev version 8773

With this version files with "umlauts" are transfered, but the filename is now damaged.
See the attachment.
I can copy with F5 or drag&drop and filename is fine, but synchronize make here a problem.

This issue I not report yet, but maybe thats helps.
Here a remote file with japanese characters exists on server and can transfer with F5 or drag&drop without any problem, but with synchronize its failed to create.
See attachment.
filename: [アニメ DVD] Dr.SLUMP -ドクタースランプ-90’ 第68話 「夏だ！海だ！アラレだ！なんだ？」 [24m37s 640x480 WMV9+WMA].wmv_snapshot_22.44_[2018.04.02_06.38.32].jpg

So do you mean it work with plain download. But does not work when synchronizing (remote to local)? Or what do you mean by "file ... its exists and is workable"?

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

I want synchronize remote to local. Winscp 5.13.4 on Windows 10 (1803 Build 17134.254) with SFTP.

Messagebox said remote file can't open, but its exists and is workable.

UPDATE:
I have seen, that files with German-Umlauts was downloading, so Umlauts is workable but I must actual hundreds times confirm to skip, but the file exists on remote side.