Description of problem: I want to to use ntrans in the .netrc file to force filenames to be all upper case. I defined ntrans specifying all lowercase letters as the "input characters" and all the corresponding UPPER case characters for the "output characters". The ftp status command shows that only a portion of the translation characters apply, even though no error message was given. Version-Release number of selected component (if applicable): ftp-0.17-32.1.2 How reproducible: Always Steps to Reproduce: 1. touch abcdefghijklmnopqrstuvw.xyz 2. use ntrans to map lower case letters to upper case in .netrc 3. use ftp invoking the .netrc paragraph, mput abc*.xyz Actual results: File is stored as ABCDEFGHIJKLMNOPqrstuvw.xyz Expected results: File shold be stored as ABCDEFGHIJKLMNOPQRSTUVW.XYZ Additional info: Console log showing the problem. (Note: server name was ussed because ftp.drussell.dnsalias.com already has another .netrc paragraph... [don@boris ~]$ ftp smtp.drussell.dnsalias.com Connected to smtp.drussell.dnsalias.com. 220 (vsFTPd 2.0.4) 530 Please login with USER and PASS. 530 Please login with USER and PASS. KERBEROS_V4 rejected as an authentication type 331 Please specify the password. 230 Login successful. ntrans abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ status Connected to smtp.drussell.dnsalias.com. Control Channel Protection Level: clear Data Channel Protection Level: clear Passive mode on Mode: stream; Type: ascii; Form: non-print; Structure: file Store unique: off; Receive unique: off Case: off; CR stripping: on Ntrans: (in) abcdefghijklmnop (out) ABCDEFGHIJKLMNOP Nmap: off No proxy connection. Hash mark printing: off; Use of PORT cmds: on Verbose: on; Bell: off; Prompting: on; Globbing: on Macros: init cd ~/junk 250 Directory successfully changed. lcd ~ Local directory now /home/don mput abc*.xyz mput abcdefghijklmnopqrstuvw.xyz? y local: abcdefghijklmnopqrstuvw.xyz remote: ABCDEFGHIJKLMNOPqrstuvw.xyz 227 Entering Passive Mode (10,10,10,250,73,213) 150 Ok to send data. 226 File receive OK. close 221 Goodbye. quit [don@boris ~]$ rpm -q ftp ftp-0.17-32.1.2 [don@boris ~]$
I found the source code, and the problem is in the cmds.c source file. The setntrans and dotrans routines.c. Also ftp_var.h defines the size of ntin and ntout character arrays for the translation tables. They both routines are hardcoded to use a maximum of 16 characters for the "in characters" and "out characters". (They could at least use "size of" so the compiler does the grunt work. :-) ) The man files do not mention an ntrans limit, I will check the FTP RFC... but I doubt there is a limit mentioned there either. So, question is.... is 16 some strategic design decision? Or perhaps a bad typo that got carried through (at least a limit of 26 would allow for the whole (English) alphabet.) Is there any reason not to fix this? With an 8 bit character set, the simplest would be to allow all 255 possible characters (x'00' can't be specified, it terminates the strings.) Alternatively, allow space for all characters permitted in a filename, but since that is operatng system/file system dependant, that leaves allowing for the maximum number of characters based on character size. Otherwise the code gets unnecessarily complicated by determining target platform at compile time... that is not worth the effort. :-) Or... if the limit should remain at 16 for some reason, produce an error/warning when the limit is exceeded. Perhaps the response to an ntrans command should be the new setting. If you like, I'll make some code changes and upload the diff files. I'll have to check if there are any other source files affected. But, this is something I can do. :-)
Created attachment 131403 [details] diff file for ftp_vars.h file
Created attachment 131404 [details] diff file for cmds.c file
I attached two diff files to increase the ntrans translation tables from 16 to 64 characters. Since I was changing the numbers anyway, I changed the "hard coded" values to use a #define value. If a future change is needed, only the #define value needs changing. :-)
Thanks for patch, it needs some more changes, now it's ok.
This was fixed in Rawhide, but an update for the current release (FC5) was not issued. At this point, I'm going to just change the resolution to the correct value. If this was an oversight and an errata for FC5 was intended, this should probably be reopened until that's done.
This is a very minor fix, no special dependencies etc. Is there a reason it can't be distributed as a yum update for FC5? Thanks.
It's fixed in FC5 now.