Bug 253972 - [ftp][autodetect] Empty listing if Windows host sends UNIX list format
Summary: [ftp][autodetect] Empty listing if Windows host sends UNIX list format
Status: RESOLVED WONTFIX
Alias: None
Product: Target Management
Classification: Tools
Component: RSE (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows Vista
: P4 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Martin Oberhuber CLA
QA Contact: Martin Oberhuber CLA
URL:
Whiteboard:
Keywords: helpwanted
Depends on:
Blocks:
 
Reported: 2008-11-05 13:32 EST by Katie CLA
Modified: 2013-05-15 16:37 EDT (History)
0 users

See Also:


Attachments
error log (6.21 KB, application/octet-stream)
2008-11-05 13:32 EST, Katie CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Katie CLA 2008-11-05 13:32:54 EST
Created attachment 117126 [details]
error log

I connect to my ftp server, which has folders in it, and try to navigate to "My Home" in RSE. It has an empty list.

Exceptions:
    See attached error.log

I created a subFolder in my FTP root, which contained a single file. I set up a filter to go to /silverso/subFolder, and it returned "File '/silverso/subFolder' not found". I also tried a filter of subFolder, and it returned Empty List.

Console output:
220 Microsoft FTP Service

USER silverso
331 Password required for silverso.

PASS ******
230 User silverso logged in.

SYST
215 Windows_NT

TYPE I
200 Type set to I.

PWD
257 "/silverso" is current directory.

NOOP
200 NOOP command successful. (x5)

CWD /silverso
250 CWD command successful.

PASV
NOOP
227 Entering Passive Mode (64,8,120,115,6,5).

200 NOOP command successful.

NOOP
LIST
200 NOOP command successful.

125 Data connection already open; Transfer starting.

226 Transfer complete.

NOOP
200 NOOP command successful. (x11)

With the NOOP commands, I put a (xNUM) beside them to show how many times that was repeated immediately after, to clean up the console output a bit.

Also requested, output from logging in to my webspace with the windows commandline ftp. I just blanked out a few bits of info.

Microsoft Windows [Version 6.0.6001]
Copyright (c) 2006 Microsoft Corporation.  All rights reserved.

C:\Users\#####>ftp #####
Connected to #####.
220 Microsoft FTP Service
User (#####:(none)): silverso
331 Password required for silverso.
Password:
230 User silverso logged in.
ftp> dir
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
drwxrwxrwx   1 owner    group               0 Jan 17 15:54 auctions.tichi.org
drwxrwxrwx   1 owner    group               0 Jul 25  2007 c5plus.exoguild.info
drwxrwxrwx   1 owner    group               0 May 26 15:27 cbm.tichi.org
drwxrwxrwx   1 owner    group               0 Jul 22 11:40 config.tichi.org
drwxrwxrwx   1 owner    group               0 Feb  2 22:59 exoguild.info
drwxrwxrwx   1 owner    group               0 Jul 23 11:41 finances.tichi.org
drwxrwxrwx   1 owner    group               0 Mar  5 21:52 kusalik.tichi.org
drwxrwxrwx   1 owner    group               0 Jul 11 13:15 logs
drwxrwxrwx   1 owner    group               0 May 22 15:02 nhbandit.tichi.org
drwxrwxrwx   1 owner    group               0 Jun 25 14:37 sql.tichi.org
drwxrwxrwx   1 owner    group               0 Nov  5 12:22 subFolder
drwxrwxrwx   1 owner    group               0 Jan 24  1:14 test.exoguild.info
drwxrwxrwx   1 owner    group               0 Feb  8 14:48 test.tichi.org
drwxrwxrwx   1 owner    group               0 Jun  3 12:49 tichi.org
drwxrwxrwx   1 owner    group               0 Jan 31 13:48 wangmedia.tichi.org
drwxrwxrwx   1 owner    group               0 Aug 30 18:02 Work
226 Transfer complete.
ftp: 1199 bytes received in 0.01Seconds 85.64Kbytes/sec.
ftp>
Comment 1 Martin Oberhuber CLA 2008-11-05 13:47:09 EST
Here is the interesting exception:

java.lang.StringIndexOutOfBoundsException: String index out of range: -1
	at java.lang.String.substring(Unknown Source)
	at org.apache.commons.net.ftp.FTPClient.__parsePathname(FTPClient.java:330)
	at org.apache.commons.net.ftp.FTPClient.printWorkingDirectory(FTPClient.java:1812)


Apparently the RSE FTP subsystem issues a "pwd" command and cannot parse the result properly. This is odd, because the result of "PWD" in the console log looks OK.

Also, I can see the "subFolder" in the output of the "dir" command in your commandline FTP session. Can you please try these in your commandline FTP session right after login:

ftp> PWD
ftp> cd /silverso/subFolder
ftp> PWD
ftp> DIR
ftp> ls -l

Another possibility why this could fail is that your remote ftp server returns "Windows_NT" as its system type, but the DIR output looks like UNIX. Please try this in RSE: When creating the FTP connection, in the wizard, expand the FTP Properties node and manually select the "UNIX" FTP Listing parser instead of the "AUTO" parser. It may also be possible to do this on the Properties page of the FTP Subsystem in an already created connection.
Comment 2 Katie CLA 2008-11-06 16:09:35 EST
The UNIX parsing fixed the issue. That is odd, the server itself is a windows machine, or so they tell me. Thank you for fixing the issue!
Comment 3 Martin Oberhuber CLA 2008-11-12 08:13:17 EST
We should try to improve the autodetect mechanism, e.g. by sending a "pwd" command before deciding on a particular listing parser. When the path returned by "pwd" is UNIX style, we should enable UNIX list parsing, which is still the one most widely used.

I'd appreciate patches from the Community for this.

Changed summary, previous value was:
empty home list in ftp
Comment 4 Martin Oberhuber CLA 2013-05-15 16:37:01 EDT
I've just tried ftp.microsoft.com - it returns SYST Windows_NT, along with PWD return / but with a Windows listing: 


230-Welcome to FTP.MICROSOFT.COM. Also visit http://www.microsoft.com/downloads.
230 User logged in.

SYST
215 Windows_NT

PWD
257 "/" is current directory.

LIST
125 Data connection already open; Transfer starting.

226 Transfer complete.

04-28-10  07:21PM       <DIR>          bussys
04-28-10  10:17PM       <DIR>          deskapps


It looks like the particular server mentioned in this report really produces an inconsistent output, and I can't see how we could auto-detect the right one. Marking as WONTFIX.