Opened 3 years ago

Last modified 3 years ago

#12464 new Bug report

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

Reported by: BettyWoodley Owned by:
Priority: normal Component: FileZilla Client
Keywords: invalid characters Cc: BettyWoodley
Component version: 3.53.1 Operating system type: Windows
Operating system version: Windows 10 Home 19041.985

Description (last modified by 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/
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/
Command:	cd "/home/wta/wta-monitor/"
Response:	New directory is: "/home/wta/wta-monitor/"
Command:	mtime "2021-05-07_23_53_01-LEDDiagnose.png"
Error:	get attrs for /home/wta/wta-monitor/ no such file or directory
Status:	Skipping download of /home/wta/wta-monitor/
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.)

Change History (1)

comment:1 by BettyWoodley, 3 years ago

Description: modified (diff)
Note: See TracTickets for help on using tickets.