Error transferring files recursively with invalid characters from unix to windows systems
|Reported by:||BettyWoodley||Owned by:|
|Component version:||3.53.1||Operating system type:||Windows|
|Operating system version:||Windows 10 Home 19041.985|
Description (last modified by )
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.)