Possible Bug: WinSCP reading * instead of %2a in Remote Files.
I've discovered something that may be a bug. It seems that WinSCP is reading %2a as an asterisk (*).
I set up a script to synchronize a number of folders for backups, for the most part its worked well. However there is a particular file that it gets hung up on. It would throw out an error like this into the log:
. 2016-08-24 16:05:22.714 File: 'C:\Users\Username\Desktop\2ndFTP\zzzzzzz%2azzzz.txt' [2016-08-24T20:04:15.345Z] [0]
. 2016-08-24 16:05:22.714 Copying "C:\Users\Username\Desktop\2ndFTP\zzzzzzz%2azzzz.txt" to remote directory started.
. 2016-08-24 16:05:22.714 Binary transfer mode selected.
. 2016-08-24 16:05:22.714 Starting upload of C:\Users\Username\Desktop\2ndFTP\zzzzzzz%2azzzz.txt
> 2016-08-24 16:05:22.714 TYPE I
< 2016-08-24 16:05:23.096 200 Type set to I
> 2016-08-24 16:05:23.096 PASV
< 2016-08-24 16:05:23.511 227 Entering Passive Mode (192,168,1,25,195,96)
. 2016-08-24 16:05:23.511 Server sent passive reply with unroutable address 192.168.1.25, using host address instead.
> 2016-08-24 16:05:23.512 STOR zzzzzzz*zzzz.txt
< 2016-08-24 16:05:24.023 150 Opening data channel for file upload to server of "/testfolder/zzzzzzz*zzzz.txt"
< 2016-08-24 16:05:24.023 550 can't access file.
. 2016-08-24 16:05:24.023 Copying files to remote side failed.
I didn't notice at first in the original log file because the file name was much longer and crazier, but eventually I saw that there was a different between how the remote filename and the local filename were being interpreted. I created a couple files with %2a somewhere in the name and the same error occurred. A very similar error occurs when trying to transfer files with %2a in the name through the GUI.
Renaming the file is unfortunately not an option in this case. Is there any way to work around this error/bug? Any help would be greatly appreciated.
I set up a script to synchronize a number of folders for backups, for the most part its worked well. However there is a particular file that it gets hung up on. It would throw out an error like this into the log:
. 2016-08-24 16:05:22.714 File: 'C:\Users\Username\Desktop\2ndFTP\zzzzzzz%2azzzz.txt' [2016-08-24T20:04:15.345Z] [0]
. 2016-08-24 16:05:22.714 Copying "C:\Users\Username\Desktop\2ndFTP\zzzzzzz%2azzzz.txt" to remote directory started.
. 2016-08-24 16:05:22.714 Binary transfer mode selected.
. 2016-08-24 16:05:22.714 Starting upload of C:\Users\Username\Desktop\2ndFTP\zzzzzzz%2azzzz.txt
> 2016-08-24 16:05:22.714 TYPE I
< 2016-08-24 16:05:23.096 200 Type set to I
> 2016-08-24 16:05:23.096 PASV
< 2016-08-24 16:05:23.511 227 Entering Passive Mode (192,168,1,25,195,96)
. 2016-08-24 16:05:23.511 Server sent passive reply with unroutable address 192.168.1.25, using host address instead.
> 2016-08-24 16:05:23.512 STOR zzzzzzz*zzzz.txt
< 2016-08-24 16:05:24.023 150 Opening data channel for file upload to server of "/testfolder/zzzzzzz*zzzz.txt"
< 2016-08-24 16:05:24.023 550 can't access file.
. 2016-08-24 16:05:24.023 Copying files to remote side failed.
I didn't notice at first in the original log file because the file name was much longer and crazier, but eventually I saw that there was a different between how the remote filename and the local filename were being interpreted. I created a couple files with %2a somewhere in the name and the same error occurred. A very similar error occurs when trying to transfer files with %2a in the name through the GUI.
Renaming the file is unfortunately not an option in this case. Is there any way to work around this error/bug? Any help would be greatly appreciated.
