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) <j...@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. > >
