Bug 196103 - ntrans does not allow long translation tables
Summary: ntrans does not allow long translation tables
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: ftp
Version: 5
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Marcela Mašláňová
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-06-21 02:55 UTC by Don Russell
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version: ftp-0.17-32.1.2.fc5
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-08-04 07:38:18 UTC
Type: ---
Embargoed:


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

Description Don Russell 2006-06-21 02:55:21 UTC
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 13:31:23 UTC
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-23 03:04:07 UTC
Created attachment 131403 [details]
diff file for ftp_vars.h file

Comment 3 Don Russell 2006-06-23 03:04:52 UTC
Created attachment 131404 [details]
diff file for cmds.c file

Comment 4 Don Russell 2006-06-23 03:08:25 UTC
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 13:20:01 UTC
Thanks for patch, it needs some more changes, now it's ok.

Comment 6 Matthew Miller 2006-08-03 15:10:16 UTC
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 15:46:43 UTC
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 07:38:18 UTC
It's fixed in FC5 now.


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