Bug 442710 - ftp case directive botches mget when mixed case filenames exit
ftp case directive botches mget when mixed case filenames exit
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: ftp (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Martin Nagy
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 442713
  Show dependency treegraph
 
Reported: 2008-04-16 08:19 EDT by ritz
Modified: 2016-07-26 19:46 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
When the "case" command was used to turn on the remote computer file name case mapping, using the "mget" command to download remote files may have caused the ftp client to overwrite the files on the client machine with the wrong content, or fail when mixed-case file names were used. For example, downloading multiple files may have resulted in a single file, that contained the content of a different file. This has been fixed, and all files are now transferred with their original content as expected.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-09 10:33:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
patch (439 bytes, patch)
2008-04-16 08:19 EDT, ritz
no flags Details | Diff
Alternate patch (497 bytes, patch)
2008-04-16 13:18 EDT, ritz
no flags Details | Diff

  None (edit)
Description ritz 2008-04-16 08:19:06 EDT
Description of problem: 
ftp can overwrite files with the wrong content or fail to get/put files when
mixed-case filenames are involved.

Version-Release number of selected component (if applicable):
ftp-0.17-47

How reproducible: 
always

Steps to Reproduce: 

1.  Login to a linux box and install/start up vsftpd.  
2.  Create the following files in /var/ftp/pub
  * Test1.out1
  * TEST2.OUT2
  * tesT3.Out3

3. Connect to ftp server

ftp> ls
227 Entering Passive Mode (9,67,58,187,198,5)
150 Here comes the directory listing.
-rw-rw-r--    1 503      503            11 Apr 11 15:33 TEST2.OUT2
-rw-rw-r--    1 503      503            11 Apr 11 15:32 Test1.out1
-rw-rw-r--    1 503      503            11 Apr 11 15:33 tesT3.Out3
226 Directory send OK.
ftp> prompt
Interactive mode off.
ftp> case
Case mapping on.
ftp> mget *
local: test2.out2 remote: TEST2.OUT2
227 Entering Passive Mode (9,67,58,187,161,53)
150 Opening BINARY mode data connection for TEST2.OUT2 (11 bytes).
226 File send OK.
11 bytes received in 0.0086 seconds (1.3 Kbytes/s)
local: test2.out2 remote: Test1.out1
227 Entering Passive Mode (9,67,58,187,23,178)
150 Opening BINARY mode data connection for Test1.out1 (11 bytes).
226 File send OK.
11 bytes received in 0.0037 seconds (2.9 Kbytes/s)
local: test2.out2 remote: tesT3.Out3
227 Entering Passive Mode (9,67,58,187,72,19)
150 Opening BINARY mode data connection for tesT3.Out3 (11 bytes).
226 File send OK.
11 bytes received in 0.006 seconds (1.8 Kbytes/s)

Actual results:  
local filename for the second 2nd and 3rd files transfered is the same as the
first.  The end result is a single file in the local directory called test2.out2
with the contents of tesT3.Out3

Expected results:  
3 files transfered with their original contents.  Only the file with all
uppercase in the name is translated to lowercase (according to the ftp manpage
at least.)

Additional info:
patch attached
Comment 1 ritz 2008-04-16 08:19:06 EDT
Created attachment 302589 [details]
patch
Comment 2 ritz 2008-04-16 13:18:31 EDT
Created attachment 302643 [details]
Alternate patch

yet another patch for the same issue.
Comment 3 Martin Nagy 2008-05-09 10:33:31 EDT
Fixed in ftp-0.17-48.fc10
Comment 4 Jaromir Hradilek 2010-07-15 07:28:06 EDT
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.

New Contents:
When the "case" command was used to turn on the remote computer file name case mapping, using the "mget" command to download remote files may have caused the ftp client to overwrite the files on the client machine with the wrong content, or fail when mixed-case file names were used. For example, downloading multiple files may have resulted in a single file, that contained the content of a different file. This has been fixed, and all files are now transferred with their original content as expected.

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