Error transferring files recursively with invalid characters from unix to windows systems

[BettyWoodley]

I want to transfer files with timestamps via sftp from a unix station (recent Debian 10) to a windows system containing invalid characters. In version 3.53.1 this stopped working as before.

One of the files I want to transfer is called 2021-05-07_23:53:01-LEDDiagnose.png. When I try to transfer this file directly, the invalid characters (":") are replaced by "_" as configured in the settings dialog Filter invalid characters from filenames and the transfer succeeds:

Status:	Starting download of /home/wta/wta-monitor/10.14.4.83/2021-05-07_23:53:01-LEDDiagnose.png
Status:	File transfer successful, transferred 295 bytes in 1 second

On my PC I now have the file 2021-05-07_23_53_01-LEDDiagnose.png available. So there is no problem with the file, the permissions or the connection (it is a small picture containing only a few pixels, that's why the file is very small).

But when I try to download the whole directory containing that file, I get the following error message in the log window:

Status:	Starting download of /home/wta/wta-monitor/10.14.4.83/2021-05-07_23_53_01-LEDDiagnose.png
Command:	cd "/home/wta/wta-monitor/10.14.4.83"
Response:	New directory is: "/home/wta/wta-monitor/10.14.4.83"
Command:	mtime "2021-05-07_23_53_01-LEDDiagnose.png"
Error:	get attrs for /home/wta/wta-monitor/10.14.4.83/2021-05-07_23_53_01-LEDDiagnose.png: no such file or directory
Status:	Skipping download of /home/wta/wta-monitor/10.14.4.83/2021-05-07_23_53_01-LEDDiagnose.png
Status:	File transfer skipped

The client requests the status of the file with the invalid characters already replaced, so the server is totally right complaining that the file 2021-05-07_23_53_01-LEDDiagnose.png is not existing in this directory. The replacement of the invalid characters should probably be done only on the client and not on the server side when downloading files.

I sync this folder periodically to my PC, so most of the files already exist on my side. The error in the log is reported before the dialog "target file already exists" opens and no matter which option I choose there, the transfer fails.

I experienced this issue with version 3.54.1 and 3.53.1. Versions 3.52.2 and before are working as expected.

(#12452 sounds somehow similar, but there I don't see any invalid characters involved.)