unicode filenames, "cannot find the file specified", odd beh
I am trying to copy (sftp) a file from A to B (both Windows machines). The destination directory is empty and there are no spaces in the directory path. If the filename contains either a μ (U+0x03BC) or µ (U+0x00B5) character, WinSCP (this is 4.1.8 b415 on WinXP) copies the file then asks "Remote file 'Foo 1µV.dat' already exists. Overwrite?" Since the directory was empty, there is nothing to overwrite and this is unexpected behavior. Regardless of the answer given -- even append -- the file appears to transfer correctly.
When trying to copy a file from A to B where the destination directory path has a space in it, files with µ (U+0x00B5) transfer correctly -- without asking about overwriting the file. Files with μ (U+0x03BC) will not transfer, reporting "System Error. Code 2. The system cannot find the file specified."
Further, if two files are transferred together or in series, one named 'Foo 1µV.dat' (U+0x00B5) and another 'Foo 1μV.dat' (U+0x03BC), the second file transferred will incorrectly overwrite the former, instead of creating a new file as it should.
If both versions of the filename already exist on the server, WinSCP always downloads the U+0x00B5 version, even if the U+0x03BC file was selected. This means a filename containing μ (U+0x03BC) cannot be transferred from the server, throwing "No such file or directory. Error code: 2. Error message from server (en): SfsStatusCode.NoSuchFile. Request code: 3."
Other sftp clients connecting to the same server, have no issues with any of the above scenarios.