mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sai Pullabhotla <sai.pullabho...@jmethods.com>
Subject Re: [jira] Commented: (FTPSERVER-287) NLST: Implementation only supports listing files in working directory [patch provided]
Date Tue, 02 Jun 2009 01:31:10 GMT
I would like to say that the results you have indicated only come from FTP
servers that actually run the UNIX's ls command when a NLST command is
received. Other servers probably adhere to the RFC by just returning names.

Here are a few tests I did with various FTP servers:

Results from Netscape's anonymous FTP site did match up with what Dennis
described. (ftp.netscape.com)

Results from GlobalScape's anonymous FTP site always returned just names. (
ftp.globalscape.com)

Results from an AS/400 FTP server (IBM's System i) always returned just
names. (Private)

Results from IPSwitch's WS_FTP server always returned just names. (
ftp.ipswitch.com)

Results from Microsoft's anonymous web site running MS FTP service also
retruns just names (ftp.microsoft.com)

Hopefully this might help making a decision.

Sai Pullabhotla
www.jMethods.com



On Mon, Jun 1, 2009 at 7:39 PM, Dennis Keller (JIRA) <jira@apache.org>wrote:

>
>    [
> https://issues.apache.org/jira/browse/FTPSERVER-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715317#action_12715317]
>
> Dennis Keller commented on FTPSERVER-287:
> -----------------------------------------
>
> Hi Niklas - I suppose my comment would be that regardless of the text of
> the RFC, if you compare the Apache FTPServer response against that of other
> FTP servers, you will see the difference (they return paths when the request
> includes a path).
>
> I included an example in my initial posting. I suppose you could interpret
> the spec literally, however I urge to you test the cases I've provided using
> other ftp servers. I believe the intent of the RFC is to behave similarly to
> a list command on a UNIX machine. If you include the path in a list command,
> the response will include the target path. The RFC says "... return a stream
> of names of files...", which does not exclude the path, if the file was
> requested with a path. For example:
>
> If I execute "nlst file.txt", I expect a response of "file.txt"
> If I execute "nlst directory/file.txt", I expect a response of
> "directory/file.txt"
> If I execute "nlst /directory/file.txt", I expect a response of
> "/directory/file.txt"
> If I execute "nlst ../parentdir/subdir/file.txt", I expect a response of
> "../parentdir/subdir/file.txt"
>
> This is how other FTP servers work and this is how unix works. The RFC is
> vague and open to interpretation, therefore we need to look to other
> implementations to find the consensus implementation. As it stands now, we
> are unable to use the apache ftp server (before the patch) because of the
> significant implementation difference.
>
> Note that my patch may not be the best solution, however there is an
> implementation issue now. So at the very least the test cases should be
> included and the implementation constructed around them. I will provide more
> examples if you require.
>
> > NLST: Implementation only supports listing files in working directory
> [patch provided]
> >
> --------------------------------------------------------------------------------------
> >
> >                 Key: FTPSERVER-287
> >                 URL: https://issues.apache.org/jira/browse/FTPSERVER-287
> >             Project: FtpServer
> >          Issue Type: Bug
> >          Components: Core
> >    Affects Versions: 1.1
> >         Environment: Fedora 10-64bit and RH 5.2-64bit, Java 1.6.0_12-64
> >            Reporter: Dennis Keller
> >             Fix For: 1.0.2, 1.1
> >
> >         Attachments: nlst.patch
> >
> >
> > The NLST formatter, as implemented on trunk is insufficient to handle any
> request other than a file within in the current working directory. Some
> examples:
> > ftp> passive
> > Passive mode on.
> > ftp> nlist /directory/file.txt
> > 227 Entering Passive Mode (127,0,0,1,179,241)
> > 150 File status okay; about to open data connection.
> > file.txt
> > 226 Closing data connection.
> > Other FTP servers return the following:
> > ftp> passive
> > Passive mode on.
> > ftp> nlist /directory/file.txt
> > 227 Entering Passive Mode (127,0,0,1,179,241)
> > 150 File status okay; about to open data connection.
> > /directory/file.txt
> > 226 Closing data connection.
> > Upon investigating, I found that the formatter will not handle absolute
> file requests, parent directory request or non-absolute child directory
> requests. It does not error, it just doesn't give useful output.
> > I've modified the code to handle the cases that I could come up with, but
> there may be other situations that need to be covered. I'm not an expert on
> the FTP specification (but what I could find was not impressive), so there
> many be additional cases that need to be covered.
> > Please consider the attached patch, with accompanying test cases
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message