You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "Dennis Keller (JIRA)" <ji...@apache.org> on 2009/04/07 02:29:12 UTC
[jira] Created: (FTPSERVER-287) NLST: Implementation only supports
listing files in working directory [patch provided]
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
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.
Re: [jira] Commented: (FTPSERVER-287) NLST: Implementation only
supports listing files in working directory [patch provided]
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Mon, Jun 1, 2009 at 10:56 AM, David Latorre <dv...@gmail.com> wrote:
> I had a look and I'm inclined to think that the request is we
> return the full pathname :-)
Let's compare with some other major servers and see what they do.
/niklas
Re: [jira] Commented: (FTPSERVER-287) NLST: Implementation only
supports listing files in working directory [patch provided]
Posted by David Latorre <dv...@gmail.com>.
I had a look and I'm inclined to think that the request is we
return the full pathname :-)
2009/6/1 Niklas Gustavsson (JIRA) <ji...@apache.org>:
>
> [ https://issues.apache.org/jira/browse/FTPSERVER-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715024#action_12715024 ]
>
> Niklas Gustavsson commented on FTPSERVER-287:
> ---------------------------------------------
>
> I've worked some on this and wrote some test cases (I had some troubles following along in the provided patch). Comparing with your examples above, we seem to return the correct reply for whatever path I throw at it. However, return only the file name, not the full path. The RFC says "The server will return a stream of names of files and no other information." which seem like we might be doing the correct (or at least acceptable) thing when returning only the file names.
>
> The test case has been added in trunk in core/src/test/java/org/apache/ftpserver/clienttests/NLSTTest.java.
>
> I'm assuming I'm missing something so please help me along :-)
>
>> 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.
>
>
Re: [jira] Commented: (FTPSERVER-287) NLST: Implementation only
supports listing files in working directory [patch provided]
Posted by David Latorre <dv...@gmail.com>.
I don't feel very comfortable with the idea of running ls (although
I'm executing several ln -s and I'm fine with it :P) for the output,
although users can reimplement any command they like ... :-) but it
doesn't look that useful, having into account that file permissions
won't be applicable when using ftpserver.
Besides, the filesystem interface abstracts the real filesystem, using
"ls" would only be possible with the nativefilesystem implementation.
Following Niklas idea we might get "extended info" fromt the
filesystem by using Apache Portable Runtime ... But i don't know if it
is worth it. We can always wait for NIO2.
I would like to implement a "permission system" where a FTPUser is
allowed or not to modify a file, retrieve it etc. Do you have any
ideas on this ?? I'm thinking that it's difficult that we can
implement a "Native" version which uses the system privileges ( I
think SSHD project did something like this, since it logged through
the PAM system ... but we can't do this having not different threads
for different connections, right? )
I guess we should use a file format ( or database table ) where the
permissions for the different files/ directories are stored. Since
many applications should have their own ACLs , do you know of any
format that we may use ?
2009/6/2 Niklas Gustavsson <ni...@protocol7.com>:
> On Tue, Jun 2, 2009 at 12:21 PM, Sai Pullabhotla
> <sa...@jmethods.com> wrote:
>> In any case, what if we give an option for running a native command when
>> NLST or LIST command is received. So, the user could configure the FTP
>> server to execute the ls command and we redirect the output of the ls
>> command back to the client. One of the advantages of allowing this for the
>> LIST command is we can actually return more information about files and
>> directories such as if an object is symbolic link, the owner etc. (of course
>> applicable mainly to *NIX systems) which cannnot be retrived using Java.
>> Something to think about.
>
> There has been some discussions around this previously, especially to
> be able to get hold of the user/group information. However, no one has
> come up with an implementation. Personally, I don't think an
> implementation based on running processes is a very good idea since it
> would likely affect both the performance and stability of the server.
> That being said, since this would be isolated to the file system,
> anyone could create an implementation, even if we did not ship it with
> FtpServer core.
>
> A more refined solution might be to use JNI rather than running
> processes, but that's beyond my competence :-)
>
> /niklas
>
Re: [jira] Commented: (FTPSERVER-287) NLST: Implementation only
supports listing files in working directory [patch provided]
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Tue, Jun 2, 2009 at 12:21 PM, Sai Pullabhotla
<sa...@jmethods.com> wrote:
> In any case, what if we give an option for running a native command when
> NLST or LIST command is received. So, the user could configure the FTP
> server to execute the ls command and we redirect the output of the ls
> command back to the client. One of the advantages of allowing this for the
> LIST command is we can actually return more information about files and
> directories such as if an object is symbolic link, the owner etc. (of course
> applicable mainly to *NIX systems) which cannnot be retrived using Java.
> Something to think about.
There has been some discussions around this previously, especially to
be able to get hold of the user/group information. However, no one has
come up with an implementation. Personally, I don't think an
implementation based on running processes is a very good idea since it
would likely affect both the performance and stability of the server.
That being said, since this would be isolated to the file system,
anyone could create an implementation, even if we did not ship it with
FtpServer core.
A more refined solution might be to use JNI rather than running
processes, but that's beyond my competence :-)
/niklas
Re: [jira] Commented: (FTPSERVER-287) NLST: Implementation only
supports listing files in working directory [patch provided]
Posted by Sai Pullabhotla <sa...@jmethods.com>.
In any case, what if we give an option for running a native command when
NLST or LIST command is received. So, the user could configure the FTP
server to execute the ls command and we redirect the output of the ls
command back to the client. One of the advantages of allowing this for the
LIST command is we can actually return more information about files and
directories such as if an object is symbolic link, the owner etc. (of course
applicable mainly to *NIX systems) which cannnot be retrived using Java.
Something to think about.
Sai Pullabhotla
www.jMethods.com
On Tue, Jun 2, 2009 at 1:51 AM, Niklas Gustavsson <ni...@protocol7.com>wrote:
> On Tue, Jun 2, 2009 at 3:31 AM, Sai Pullabhotla
> <sa...@jmethods.com> wrote:
> > 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.
>
> One addition to this list, FileZilla works as described by Dennis.
>
> /niklas
>
Re: [jira] Commented: (FTPSERVER-287) NLST: Implementation only
supports listing files in working directory [patch provided]
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Tue, Jun 2, 2009 at 8:51 AM, Niklas Gustavsson <ni...@protocol7.com> wrote:
> On Tue, Jun 2, 2009 at 3:31 AM, Sai Pullabhotla
> <sa...@jmethods.com> wrote:
>> 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.
>
> One addition to this list, FileZilla works as described by Dennis.
Another one, proftpd prints full path, but does not support parent
directories (".." seems to be ignored). Does support home directory
paths, but translated them to absolute paths (from the root of the
file system).
All of this seems to be a mess, not sure that we conclude that we do
the wrong, nor the right thing at the moment. At least clients can not
assume anything and thus probably have to find the file names (without
the path) in whatever gets returned. Of course, the client knows the
path already, since it sent it.
Dennis, could you maybe describe some further on why you need to full
path and how your client interoperates with servers that do not full
support this (like proftpd which is a major player in this area).
/niklas
Re: [jira] Commented: (FTPSERVER-287) NLST: Implementation only
supports listing files in working directory [patch provided]
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Tue, Jun 2, 2009 at 3:31 AM, Sai Pullabhotla
<sa...@jmethods.com> wrote:
> 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.
One addition to this list, FileZilla works as described by Dennis.
/niklas
Re: [jira] Commented: (FTPSERVER-287) NLST: Implementation only
supports listing files in working directory [patch provided]
Posted by Sai Pullabhotla <sa...@jmethods.com>.
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) <ji...@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.
>
>
[jira] Commented: (FTPSERVER-287) NLST: Implementation only
supports listing files in working directory [patch provided]
Posted by "Niklas Gustavsson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FTPSERVER-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715024#action_12715024 ]
Niklas Gustavsson commented on FTPSERVER-287:
---------------------------------------------
I've worked some on this and wrote some test cases (I had some troubles following along in the provided patch). Comparing with your examples above, we seem to return the correct reply for whatever path I throw at it. However, return only the file name, not the full path. The RFC says "The server will return a stream of names of files and no other information." which seem like we might be doing the correct (or at least acceptable) thing when returning only the file names.
The test case has been added in trunk in core/src/test/java/org/apache/ftpserver/clienttests/NLSTTest.java.
I'm assuming I'm missing something so please help me along :-)
> 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.
[jira] Updated: (FTPSERVER-287) NLST: Implementation only supports
listing files in working directory [patch provided]
Posted by "Dennis Keller (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FTPSERVER-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dennis Keller updated FTPSERVER-287:
------------------------------------
Attachment: nlst.patch
Patch to support more NLST request types.
> 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
> 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.
[jira] Closed: (FTPSERVER-287) NLST: Implementation only supports
listing files in working directory [patch provided]
Posted by "Dennis Keller (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FTPSERVER-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dennis Keller closed FTPSERVER-287.
-----------------------------------
> 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.
[jira] Commented: (FTPSERVER-287) NLST: Implementation only
supports listing files in working directory [patch provided]
Posted by "David Latorre (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FTPSERVER-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12716251#action_12716251 ]
David Latorre commented on FTPSERVER-287:
-----------------------------------------
By the way, PureFTPD and vsFTPD in Linux also seem to behave as described ( I didn't check the $HOME option though).
Still I also think that clients shouldn't rely on the output of the FTP server ... since you're expecting that the output filename be equal to the nlist argument , why don't you use it in your program?
With your patch, what's the behaviour you get when you list a directory ? For example: NLIST /myDir1/mydDir2
Would return just the filenames ? or results of the kind: /myDir1/myDir2/file.txt ?
" ls" and Pure-FTPD would return just the filenames ... so it is not very useful to have NLIST return the full paths only sometimes.
> 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.
[jira] Commented: (FTPSERVER-287) NLST: Implementation only
supports listing files in working directory [patch provided]
Posted by "David Latorre (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FTPSERVER-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12716209#action_12716209 ]
David Latorre commented on FTPSERVER-287:
-----------------------------------------
Comments by Sai in the mailing list:
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
> 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.
[jira] Commented: (FTPSERVER-287) NLST: Implementation only
supports listing files in working directory [patch provided]
Posted by "Dennis Keller (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FTPSERVER-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12716384#action_12716384 ]
Dennis Keller commented on FTPSERVER-287:
-----------------------------------------
Interesting discussion. Thanks to all for the evaluation. It seems that there is much disparity amongst the various FTP server implementations and that the logic in the Apache FTP server is as correct as the other server's implementations :) I suppose this is what happens when specifications are vague!
Your suggestions not to rely on the output of NLIST are good and we will change our code so that it does not use the output of NLST as input to other requests.
> 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.
[jira] Updated: (FTPSERVER-287) NLST: Implementation only supports
listing files in working directory [patch provided]
Posted by "Niklas Gustavsson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FTPSERVER-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Niklas Gustavsson updated FTPSERVER-287:
----------------------------------------
Fix Version/s: 1.1
1.0.2
> 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.
[jira] Commented: (FTPSERVER-287) NLST: Implementation only
supports listing files in working directory [patch provided]
Posted by "David Latorre (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FTPSERVER-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12716210#action_12716210 ]
David Latorre commented on FTPSERVER-287:
-----------------------------------------
By Niklas Gustavsson:
One addition to this list, FileZilla works as described by Dennis.
Another one, proftpd prints full path, but does not support parent
directories (".." seems to be ignored). Does support home directory
paths, but translated them to absolute paths (from the root of the
file system).
All of this seems to be a mess, not sure that we conclude that we do
the wrong, nor the right thing at the moment. At least clients can not
assume anything and thus probably have to find the file names (without
the path) in whatever gets returned. Of course, the client knows the
path already, since it sent it.
Dennis, could you maybe describe some further on why you need to full
path and how your client interoperates with servers that do not full
support this (like proftpd which is a major player in this area).
> 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.
[jira] Resolved: (FTPSERVER-287) NLST: Implementation only supports
listing files in working directory [patch provided]
Posted by "Dennis Keller (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FTPSERVER-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dennis Keller resolved FTPSERVER-287.
-------------------------------------
Resolution: Won't Fix
FTPServer NLST appears to be working as designed.
> 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.
[jira] Commented: (FTPSERVER-287) NLST: Implementation only
supports listing files in working directory [patch provided]
Posted by "Dennis Keller (JIRA)" <ji...@apache.org>.
[ 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.