Bug 196103 - ntrans does not allow long translation tables
ntrans does not allow long translation tables
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: ftp (Show other bugs)
5
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Marcela Mašláňová
Ben Levenson
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-06-20 22:55 EDT by Don Russell
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version: ftp-0.17-32.1.2.fc5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-04 03:38:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
diff file for ftp_vars.h file (358 bytes, text/plain)
2006-06-22 23:04 EDT, Don Russell
no flags Details
diff file for cmds.c file (574 bytes, text/plain)
2006-06-22 23:04 EDT, Don Russell
no flags Details

  None (edit)
Description Don Russell 2006-06-20 22:55:21 EDT
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 ~]$
Comment 1 Don Russell 2006-06-21 09:31:23 EDT
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. :-)
Comment 2 Don Russell 2006-06-22 23:04:07 EDT
Created attachment 131403 [details]
diff file for ftp_vars.h file
Comment 3 Don Russell 2006-06-22 23:04:52 EDT
Created attachment 131404 [details]
diff file for cmds.c file
Comment 4 Don Russell 2006-06-22 23:08:25 EDT
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. :-)

Comment 5 Marcela Mašláňová 2006-07-26 09:20:01 EDT
Thanks for patch, it needs some more changes, now it's ok.
Comment 6 Matthew Miller 2006-08-03 11:10:16 EDT
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.
Comment 7 Don Russell 2006-08-03 11:46:43 EDT
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.
Comment 8 Marcela Mašláňová 2006-08-04 03:38:18 EDT
It's fixed in FC5 now.

Note You need to log in before you can comment on or make changes to this bug.