I recently tried to use CoreFTP (LE, Version 1.3c, build 1447.5) to download a bunch of mp3 files that I have on a central server machine to a laptop.
The first time that I tried this, I found that not all of the files sucessfully downloaded. So I tried the process again, and encountered the same problem, but this time observed that all of the problematic files seem to have special (i.e. non-ascii) characters in their filenames.
Below is the contents of the log window when I tried downloading just one of the problematic files:
Connect socket #716 to 192.168.1.100, port 1629...
150 File OK.
550 Requested action not taken. File unavailable.
02 ~ Albéniz ~ Granada.mp3 - 0 bytes transferred
Transfer time: 00:00:01
Note that the special character in this case is the 'é'. Note that this character is being correctly displayed in both the remote view as well as in the local view (the local file, of course, has 0 bytes since the transfer failed). This was obtained with the default view - encode - ansi setting.
Searching here on the forums, I found that others seem to have encountered similar issues:
The main relevant solutions from the above seems to be
1) From within Core FTP, go to view - encode - unicode
2) Right click on the remote directory, select misc - font - RESET font
If I try solution 1), it either causes the 'é' to disappear (i.e. in both the remote and local view the filename now is 02 ~ Albniz ~ Granada.mp3) or else it causes it to e displayed as a '?' (i.e. in both the remote and local view the filename now is 02 ~ Alb?niz ~ Granada.mp3). I have NO idea why it sometimes behaves one way, and sometimes the other, but in trying to verify this bug before doing this posting, I have seen both modes. This is truly bizarre!
Solution 2) does not seem to have any effect (altho maybe when I tried it, it was what caused the above mode change to happen).
Does anyone have any idea what is going on here? I generally love CoreFTP and would like to continue using it but this is a killer bug for now...
Notes:
a) both the server machine and the client are running win xp pro sp2 with all of the latest upgrades, and with US english as the primary language.
b) when I examined the ftp server's log files, it reported attempts to load a file named either
both of which are incorrect; this HAS to be why the transfer is failing, but I am puzzled as to why ansi view causes the wrong filename to be sent to the server when it displays it correctly.
>I'm pretty sure it's not the 'é' that is causing the problem based on this
I still suspect that it must be based on the fact that every file that I fail to download has some kind of non-ascii char in it while every file without any special chars does download. (This statement is true for the few mp3 file directories that I examined, but there were many more that I did not examine, so maybe this is not conclusive, but I still suspect that it is the problem as the discussion below will iluminate.)
What may well be the case ia that there is something peculiar to my machine that is hard for you to duplicate.
>Are you using an english version of XP?
As noted in the original post, am using a US english version of xp pro.
To follow up with a version of your test, here is exactly what I did:
1) in windows explorer on the server machine, copy the name of one of the bum files (02 ~ Albéniz ~ Granada.mp3) and paste that name into an email that I sent to myself
2) on the server machine, start up the ftp server (I am using a free one, JSCAPE Secure FTP Server 1.2, that I downloaded from cnet)
3) on the client machine, I took an old text file, copied it into a certain directory that I want to work from, and simply renamed it to the bum name (02 ~ Albéniz ~ Granada.mp3) that I copied from the email sent previously
4) opened up Core FTP and uploaded the file to the server, then deleted the client machine's local version (probably not necessary), and then downloaded the file from the server; note that view was always set to ansi when using Core FTP
The Core FTP logs for 2 attempts of doing the above procedure are below.
Note that for the first attempt, a 501 error is listed on BOTH the store and retrieve operations. However, the complete store/retrieve cycle appears to have actually worked, since 159 bytes is actually the size of the file.
I was puzzled as to why a 501 error occurred on the retrieve instead of the 550 error that I originally reported, so I tried the exact same procedure again. This time a 550 error WAS observed, as shown in the second set of logs.
I have no idea why this inconsistency is happening...
I am also including below the JSCAPE ftp server logs for the second attempt. Note that JSCAPE is always receiving "Alb?niz" as the filename, so this has GOT to be why the error is occuring.
Welcome to Core FTP, release ver 1.3c, build 1447.5 (U) -- (c) 2003-2006
WinSock 2.0
Mem -- 1,047,924 KB, Virt -- 2,097,024 KB
Started on Wednesday August 30, 2006 at 14:08:PM
Connect socket #468 to 192.168.1.100, port 21...
220 JSCAPE Secure FTP Server 1.2
USER laptop
331 User name okay, need password.
PASS **********
230 User logged in, proceed.
SYST
215 Unix DataType: L8
Keep alive on...
PWD
257 "/"
PASV
227 (192,168,1,100,15,213)
LIST -al
Connect socket #512 to 192.168.1.100, port 4053...
150 File OK.
250 File operation OK.
Transferred 1,114 bytes in 0.070 seconds
PWD
257 "/"
TYPE I
200 Command OK.
PASV
227 (192,168,1,100,15,214)
STOR 02 ~ Albéniz ~ Granada.mp3
Connect socket #552 to 192.168.1.100, port 4054...
150 File OK.
250 File operation OK.
02 ~ Albéniz ~ Granada.mp3 - 159 bytes transferred
MDTM 20060216202406 02 ~ Albéniz ~ Granada.mp3
501 Syntax error in parameters or arguments.
Transfer time: 00:00:00
REST 0
350 Ready for next command.
TYPE I
200 Command OK.
PWD
257 "/"
TYPE A
200 Command OK.
REST 0
350 Ready for next command.
TYPE I
200 Command OK.
PWD
257 "/"
TYPE I
200 Command OK.
PASV
227 (192,168,1,100,15,215)
RETR 02 ~ Albéniz ~ Granada.mp3
Connect socket #556 to 192.168.1.100, port 4055...
150 File OK.
250 File operation OK.
02 ~ Albéniz ~ Granada.mp3 - 159 bytes transferred
MDTM 02 ~ Albéniz ~ Granada.mp3
501 Syntax error in parameters or arguments.
Transfer time: 00:00:00
NOOP
200 Command OK.