Description of problem: lftp will list, but not wildcard download a file with non-ascii (ISO-8859-1) characters in its name, from another system. Version-Release number of selected component (if applicable): lftp-3.5.14-2.fc8 ftp-0.17-42.fc8 How reproducible: Always Steps to Reproduce: 1. lftp <uri of a remote directory> 2. dir *28* 3. mget *28* Actual results: The file, with accents in its name, is listed, but mget won't download it. Expected results: Same files shown in dir should also download. Additional info: ftp works as expected, both on local system, and the remote system I am downloading from. Version of ftp on remote system: ls -l /usr/bin/ftp -r-xr-xr-x 1 root bin 80592 Jun 23 2002 /usr/bin/ftp file /usr/bin/ftp /usr/bin/ftp: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, stripped
After downloading the file with ftp, I have noticed that I can read it with simple Unix commands such as cat and wc, but OpenOffice openoffice.org-writer-2.3.0-5.1.fc8 will not, unless I copy the file to a filename without special characters. So, perhaps the crux of the problem is that different system components treat wildcarding of file names differently.
Works for me. I can't reproduce it. Can you send the version of ftp server and list of your commands please ? Thanks
I have constructed a loopback example, using the following: vsftpd-2.0.5-19.fc8 lftp-3.5.14-2.fc8 ftp-0.17-42.fc8 I put some files in the top of my user area, subdirectory EE. The example shows I can list all 5 with lftp, but mget only transfers 3 of them. A typescript file will be attached.
Created attachment 225421 [details] Typescript showing download of only 3 files instead of expected 5. Contains ISO8859-1 accented characters.
I tried everything as you said but I can't reproduce it and everything works as it should. I have a feeling that the issue is somewhere else. For example, on my system, ls -b doesn't escape 'a' with grave accent, but instead it is displayed correctly.
Re-tested today, both with local loopback, and with the system where I first saw the bug. So I'll close this bug.