[jira] [Commented] (FTPSERVER-337) XSD Does Not Support Property Placeholders for Attributes
[ https://issues.apache.org/jira/browse/FTPSERVER-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15467731#comment-15467731 ] David Latorre commented on FTPSERVER-337: - True. I have closed FTPSERVER-282 stating it is a duplicate. I hope that's ok. It seems that the guys at camel have solved this issue with their own component: http://camel.apache.org/using-propertyplaceholder.html The second option, as Niklas says is to modify the XSD(since I don't think https://jira.spring.io/browse/SPR-4466 is going to be addressed any time soon) so we can support Strings in those properties; we might add a regex restriction to improvw validation, but I would rather try to resolve properties earlier... Francisco, would you like to contribute a solution for this issue? > XSD Does Not Support Property Placeholders for Attributes > - > > Key: FTPSERVER-337 > URL: https://issues.apache.org/jira/browse/FTPSERVER-337 > Project: FtpServer > Issue Type: Improvement >Affects Versions: 1.0.3 >Reporter: Nick Padgett > Fix For: 1.1.0 > > > For example: -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (FTPSERVER-282) Spring placeholder configuration
[
https://issues.apache.org/jira/browse/FTPSERVER-282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Latorre closed FTPSERVER-282.
---
Resolution: Duplicate
Closed as duplicate of FTPSERVER-337 (the latter issue contains some comments)
> Spring placeholder configuration
>
>
> Key: FTPSERVER-282
> URL: https://issues.apache.org/jira/browse/FTPSERVER-282
> Project: FtpServer
> Issue Type: Improvement
> Components: Server
>Affects Versions: 1.0.0
>Reporter: Markus Wolf
> Fix For: 1.1.0
>
>
> The spring configuration of the ftpserver should allow property placeholder
> configuration possibility.
> Currently the XSD spedifies the properties on the listener and
> data-connection as int values. This removes the ${...} syntax used normally
> for spring property configuration.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (FTPSERVER-435) FTPClient - 3.0.1 - Randomly throwing connection timed out error during listfile / connect
[ https://issues.apache.org/jira/browse/FTPSERVER-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre closed FTPSERVER-435. --- Resolution: Won't Fix Assignee: David Latorre > FTPClient - 3.0.1 - Randomly throwing connection timed out error during > listfile / connect > -- > > Key: FTPSERVER-435 > URL: https://issues.apache.org/jira/browse/FTPSERVER-435 > Project: FtpServer > Issue Type: Bug >Reporter: vijayan >Assignee: David Latorre >Priority: Critical > > Previously we were using common-net-2.2 version and at sometimes we used to > get FTPconnectionclosedexception. This was resolved by upgrading to > commons-net-3.0.1 version using control keep-alive timeout feature. Now we > are facing another issue in a random time interval in our production > environment. Most of the times it works fine but at time during > ftpclient.listfiles /ftpclient.connect call we are getting the connection > timed out exception. Please see the exception stacktrace. > java.net.ConnectException: Connection timed out > at java.net.PlainSocketImpl.socketConnect(Native Method) > at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351) > at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213) > at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200) > at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366) > at java.net.Socket.connect(Socket.java:529) > at > org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:726) > at > org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2990) > at > org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2965) > at org.apache.commons.net.ftp.FTPClient.listFiles(FTPClient.java:2685) > > java.net.ConnectException: Connection timed out > at java.net.PlainSocketImpl.socketConnect(Native Method) > at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351) > at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213) > at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200) > at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366) > at java.net.Socket.connect(Socket.java:529) > at org.apache.commons.net.SocketClient.connect(SocketClient.java:168) > at org.apache.commons.net.SocketClient.connect(SocketClient.java:189) > Neven seen / faced this kind of exception when using 2.2 version. This is > been occurring after the upgradation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FTPSERVER-435) FTPClient - 3.0.1 - Randomly throwing connection timed out error during listfile / connect
[ https://issues.apache.org/jira/browse/FTPSERVER-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15187055#comment-15187055 ] David Latorre commented on FTPSERVER-435: - This is a normal timeout when trying to connect to the data channel. It might be caused by a faulty network connection or some firewall dropping packets. Increasing the timeout value in your FTP Client might help (or not, depending on the specific cause). > FTPClient - 3.0.1 - Randomly throwing connection timed out error during > listfile / connect > -- > > Key: FTPSERVER-435 > URL: https://issues.apache.org/jira/browse/FTPSERVER-435 > Project: FtpServer > Issue Type: Bug >Reporter: vijayan >Priority: Critical > > Previously we were using common-net-2.2 version and at sometimes we used to > get FTPconnectionclosedexception. This was resolved by upgrading to > commons-net-3.0.1 version using control keep-alive timeout feature. Now we > are facing another issue in a random time interval in our production > environment. Most of the times it works fine but at time during > ftpclient.listfiles /ftpclient.connect call we are getting the connection > timed out exception. Please see the exception stacktrace. > java.net.ConnectException: Connection timed out > at java.net.PlainSocketImpl.socketConnect(Native Method) > at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351) > at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213) > at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200) > at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366) > at java.net.Socket.connect(Socket.java:529) > at > org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:726) > at > org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2990) > at > org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2965) > at org.apache.commons.net.ftp.FTPClient.listFiles(FTPClient.java:2685) > > java.net.ConnectException: Connection timed out > at java.net.PlainSocketImpl.socketConnect(Native Method) > at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351) > at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213) > at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200) > at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366) > at java.net.Socket.connect(Socket.java:529) > at org.apache.commons.net.SocketClient.connect(SocketClient.java:168) > at org.apache.commons.net.SocketClient.connect(SocketClient.java:189) > Neven seen / faced this kind of exception when using 2.2 version. This is > been occurring after the upgradation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FTPSERVER-449) Custom SocketFactory and ServerSocketFactory in DataConnectionConfigurationFactory.
[ https://issues.apache.org/jira/browse/FTPSERVER-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13776537#comment-13776537 ] David Latorre commented on FTPSERVER-449: - What kind of cases are you thinking of? Anyway, feel free to provide a patch. > Custom SocketFactory and ServerSocketFactory in > DataConnectionConfigurationFactory. > --- > > Key: FTPSERVER-449 > URL: https://issues.apache.org/jira/browse/FTPSERVER-449 > Project: FtpServer > Issue Type: New Feature > Components: Core >Reporter: Mathias Schwaninger >Priority: Minor > > Would like to have a possibility to use custom SocketFactory and > ServerSocketFactory in DataConnectionConfigurationFactory. > That could be used for special use-cases for active and passive data > connections in IODataConnectionFactory. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FTPSERVER-320) Passive Data connections are slow when using SSL
[ https://issues.apache.org/jira/browse/FTPSERVER-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13776535#comment-13776535 ] David Latorre commented on FTPSERVER-320: - Can anybody apply the patch? I'm quite busy with work and I don't have git installed (nor I know how to use it). > Passive Data connections are slow when using SSL > > > Key: FTPSERVER-320 > URL: https://issues.apache.org/jira/browse/FTPSERVER-320 > Project: FtpServer > Issue Type: Improvement > Components: Core >Affects Versions: 1.0.2 >Reporter: Sai Pullabhotla >Assignee: David Latorre > Fix For: 1.1.0 > > Attachments: IODataConnectionFactory.java.patch > > > Creation of passive data sockets is slow when using SSL. The issue is that > the code calls InetAddress.getHostName() method which performs a reverse name > lookup. This is an expensive operation (at least on all the systems I've > tried). We really don't have a need to get the host name, so change the code > to get string version of the IP address and use it instead. More information > on this issue is available at > http://www.mail-archive.com/dev@mina.apache.org/msg13644.html. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FTPSERVER-320) Passive Data connections are slow when using SSL
[ https://issues.apache.org/jira/browse/FTPSERVER-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre updated FTPSERVER-320: Attachment: IODataConnectionFactory.java.patch > Passive Data connections are slow when using SSL > > > Key: FTPSERVER-320 > URL: https://issues.apache.org/jira/browse/FTPSERVER-320 > Project: FtpServer > Issue Type: Improvement > Components: Core >Affects Versions: 1.0.2 >Reporter: Sai Pullabhotla >Assignee: David Latorre > Fix For: 1.1.0 > > Attachments: IODataConnectionFactory.java.patch > > > Creation of passive data sockets is slow when using SSL. The issue is that > the code calls InetAddress.getHostName() method which performs a reverse name > lookup. This is an expensive operation (at least on all the systems I've > tried). We really don't have a need to get the host name, so change the code > to get string version of the IP address and use it instead. More information > on this issue is available at > http://www.mail-archive.com/dev@mina.apache.org/msg13644.html. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (FTPSERVER-320) Passive Data connections are slow when using SSL
[ https://issues.apache.org/jira/browse/FTPSERVER-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre reopened FTPSERVER-320: - Assignee: David Latorre I think it makes sense that we get rid of the reverse DNS lookup in the stable/1.0.x branch. All the other improvements by Sai are available in trunk. > Passive Data connections are slow when using SSL > > > Key: FTPSERVER-320 > URL: https://issues.apache.org/jira/browse/FTPSERVER-320 > Project: FtpServer > Issue Type: Improvement > Components: Core >Affects Versions: 1.0.2 >Reporter: Sai Pullabhotla >Assignee: David Latorre > Fix For: 1.1.0 > > > Creation of passive data sockets is slow when using SSL. The issue is that > the code calls InetAddress.getHostName() method which performs a reverse name > lookup. This is an expensive operation (at least on all the systems I've > tried). We really don't have a need to get the host name, so change the code > to get string version of the IP address and use it instead. More information > on this issue is available at > http://www.mail-archive.com/dev@mina.apache.org/msg13644.html. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FTPSERVER-433) Issues with data transfer for explicit SSL connections
[ https://issues.apache.org/jira/browse/FTPSERVER-433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13477730#comment-13477730 ] David Latorre commented on FTPSERVER-433: - I would suspect some bug in FileZilla. For instance, there is a bug in WinSCP (or the library it uses for SSL ) where , depending on the file size, the TLS_CLOSE_NOTIFY message is ill-formed. Java is a bit pick about this, and will throw an Exception in this case. What version of Filezilla are you using? Can you reproduce this problem with every version? Does this problem arise only for some file contents? (Write a text file of the same length as this one and with a character repeting itself as many times as necessary "..." and check again ). > Issues with data transfer for explicit SSL connections > -- > > Key: FTPSERVER-433 > URL: https://issues.apache.org/jira/browse/FTPSERVER-433 > Project: FtpServer > Issue Type: Bug > Environment: Linux, java version "1.6.0_30", apache-ftpserver-1.0.5 >Reporter: Søren Juul > Attachments: output.txt.gz > > > When using the sample configuration with SSL in explicit mode, some clients > (e.g. FileZilla) have problems transferring. There is not problems browsing > data, but when uploading the transfers cuts out regularly, and the transfer > connections must be restarted. Bellow is sample output from the server log > and FileZilla log. > Server log: http://pastebin.com/VBbvux2G > FileZilla log: http://pastebin.com/NP6Yh44s -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (FTPSERVER-369) maxLogin is reached immediately
[
https://issues.apache.org/jira/browse/FTPSERVER-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Latorre closed FTPSERVER-369.
---
> maxLogin is reached immediately
>
>
> Key: FTPSERVER-369
> URL: https://issues.apache.org/jira/browse/FTPSERVER-369
> Project: FtpServer
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.0.4
> Environment: Linux or Windows
>Reporter: Aniceto Pérez y Madrid
>Assignee: David Latorre
> Fix For: 1.0.5, 1.1.0
>
> Attachments: ftp4j-1.5.jar, Main.java
>
>
> I've created a simple program loop which open, connect and disconnect. If the
> max-logins parameter is set to 10, the message "Too many users logged in,
> user will be disconnected" is issued after 10 loops
> The cause is in DefaultFtpStatistics. In this function
>
> public synchronized void setLogout(final FtpIoSession session) {
> User user = session.getUser();
> if (user == null) {
> return;
> }
> currLogins.decrementAndGet();
> session.getUser() always returns null, so never currLogins.decrementAndGet()
> is called. My workaround is to put that statement before testing user null
> state.
> Why session.getUser() return null is out of my knowledge.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FTPSERVER-369) maxLogin is reached immediately
[
https://issues.apache.org/jira/browse/FTPSERVER-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Latorre resolved FTPSERVER-369.
-
Resolution: Fixed
Fixed in #942689 http://svn.apache.org/viewcvs?view=rev&rev=942689
> maxLogin is reached immediately
>
>
> Key: FTPSERVER-369
> URL: https://issues.apache.org/jira/browse/FTPSERVER-369
> Project: FtpServer
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.0.4
> Environment: Linux or Windows
>Reporter: Aniceto Pérez y Madrid
>Assignee: David Latorre
> Fix For: 1.0.5, 1.1.0
>
> Attachments: ftp4j-1.5.jar, Main.java
>
>
> I've created a simple program loop which open, connect and disconnect. If the
> max-logins parameter is set to 10, the message "Too many users logged in,
> user will be disconnected" is issued after 10 loops
> The cause is in DefaultFtpStatistics. In this function
>
> public synchronized void setLogout(final FtpIoSession session) {
> User user = session.getUser();
> if (user == null) {
> return;
> }
> currLogins.decrementAndGet();
> session.getUser() always returns null, so never currLogins.decrementAndGet()
> is called. My workaround is to put that statement before testing user null
> state.
> Why session.getUser() return null is out of my knowledge.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (FTPSERVER-369) maxLogin is reached immediately
[
https://issues.apache.org/jira/browse/FTPSERVER-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Latorre reassigned FTPSERVER-369:
---
Assignee: David Latorre
> maxLogin is reached immediately
>
>
> Key: FTPSERVER-369
> URL: https://issues.apache.org/jira/browse/FTPSERVER-369
> Project: FtpServer
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.0.4
> Environment: Linux or Windows
>Reporter: Aniceto Pérez y Madrid
>Assignee: David Latorre
> Fix For: 1.0.5, 1.1.0
>
> Attachments: ftp4j-1.5.jar, Main.java
>
>
> I've created a simple program loop which open, connect and disconnect. If the
> max-logins parameter is set to 10, the message "Too many users logged in,
> user will be disconnected" is issued after 10 loops
> The cause is in DefaultFtpStatistics. In this function
>
> public synchronized void setLogout(final FtpIoSession session) {
> User user = session.getUser();
> if (user == null) {
> return;
> }
> currLogins.decrementAndGet();
> session.getUser() always returns null, so never currLogins.decrementAndGet()
> is called. My workaround is to put that statement before testing user null
> state.
> Why session.getUser() return null is out of my knowledge.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-369) maxLogin is reached immediately
[
https://issues.apache.org/jira/browse/FTPSERVER-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12865702#action_12865702
]
David Latorre commented on FTPSERVER-369:
-
Hello Aniceto,
After running your code I see that the problem is with our handling of the
REIN command. I'm fixing the bug but actually you don't need to use REIN at all
in your code so as a quick fix you may remove these lines:
try {
ftp.logout();
} catch (Exception ee) {
}
Other java libraries will send the 'QUIT' command in the logout method rather
than REIN (in your provided library, they're sending QUIT when disconnect is
called). There's no reason to call REIN before QUIT so just calling
ftp.disconnect is completely ok.
> maxLogin is reached immediately
>
>
> Key: FTPSERVER-369
> URL: https://issues.apache.org/jira/browse/FTPSERVER-369
> Project: FtpServer
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.0.4
> Environment: Linux or Windows
>Reporter: Aniceto Pérez y Madrid
> Fix For: 1.0.5, 1.1.0
>
> Attachments: ftp4j-1.5.jar, Main.java
>
>
> I've created a simple program loop which open, connect and disconnect. If the
> max-logins parameter is set to 10, the message "Too many users logged in,
> user will be disconnected" is issued after 10 loops
> The cause is in DefaultFtpStatistics. In this function
>
> public synchronized void setLogout(final FtpIoSession session) {
> User user = session.getUser();
> if (user == null) {
> return;
> }
> currLogins.decrementAndGet();
> session.getUser() always returns null, so never currLogins.decrementAndGet()
> is called. My workaround is to put that statement before testing user null
> state.
> Why session.getUser() return null is out of my knowledge.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-369) maxLogin is reached immediately
[
https://issues.apache.org/jira/browse/FTPSERVER-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12865114#action_12865114
]
David Latorre commented on FTPSERVER-369:
-
In my tests, user is not null if you have logged in. And currLogins only gets
incremented after a successful login :) If it wasn't for the "null user" I
would think it is just a race condition for the user count is decremented after
the reply to the QUIT command has been issued - so it is possible that you try
to connect before the logged out user has been removed of the currLogins count.
Could you provide any details about your environment? What version of FTPServer
are you using? Did you implement your own user manager or made any changes to
the codebase?
> maxLogin is reached immediately
>
>
> Key: FTPSERVER-369
> URL: https://issues.apache.org/jira/browse/FTPSERVER-369
> Project: FtpServer
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.0.4
> Environment: Linux or Windows
>Reporter: Aniceto Pérez y Madrid
> Fix For: 1.0.5, 1.1.0
>
>
> I've created a simple program loop which open, connect and disconnect. If the
> max-logins parameter is set to 10, the message "Too many users logged in,
> user will be disconnected" is issued after 10 loops
> The cause is in DefaultFtpStatistics. In this function
>
> public synchronized void setLogout(final FtpIoSession session) {
> User user = session.getUser();
> if (user == null) {
> return;
> }
> currLogins.decrementAndGet();
> session.getUser() always returns null, so never currLogins.decrementAndGet()
> is called. My workaround is to put that statement before testing user null
> state.
> Why session.getUser() return null is out of my knowledge.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-370) Include in the user profile the the user and group owner for new ones
[ https://issues.apache.org/jira/browse/FTPSERVER-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12861384#action_12861384 ] David Latorre commented on FTPSERVER-370: - My suggestion is that you create an FTPlet which intercepts onUploadEnd method and changes the permissions to the desired ones. Changing file permissions won't happen at least until NIO 2 but still I think there's much room for improvement in this area Can't you use any of the methods listed in our wiki page to bind to port 21 while running as a regular user? > Include in the user profile the the user and group owner for new ones > - > > Key: FTPSERVER-370 > URL: https://issues.apache.org/jira/browse/FTPSERVER-370 > Project: FtpServer > Issue Type: Wish > Components: Core > Environment: Any >Reporter: Aniceto Pérez y Madrid > Fix For: WISHLIST > > > Frequently it's required to run Ftpserver as root in Linux to be able to bind > to port 21. The good part is it can read and write anything. The bad part is > all files and folders are created as root user and group and sometimes that > is not good. > It would be interesting to have optional user properties to > - set the user and group attributes for new files and folders > - select to force or not user:group attributes for new ones > I think files and folders readability should only be restricted by the > underlying OS and the user running ftpserver. > Probably that feature maybe initially available for Linux and Unix platforms, > later for Windows and another ones. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-361) Provide more information on command execution to Ftplets - especially file created in STOU
[ https://issues.apache.org/jira/browse/FTPSERVER-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851302#action_12851302 ] David Latorre commented on FTPSERVER-361: - We can do this but my suggestion is that you do not rely on the provided DefaultFtpLet. In our case, we ended up 'cloning' DefaultFtpLet, but changing some method bodies / signatures in order to fit our needs and this is quite common a need for other users as well. > Provide more information on command execution to Ftplets - especially file > created in STOU > -- > > Key: FTPSERVER-361 > URL: https://issues.apache.org/jira/browse/FTPSERVER-361 > Project: FtpServer > Issue Type: Improvement > Components: Ftplets >Affects Versions: 1.0.4 >Reporter: Richard Evans > > To monitor file uploads, I can configure an Ftplet and override onUploadEnd > and onUploadUniqueEnd in DefaultFtplet. However I cannot find a way to > determine the real file that was written in the upload. > For a non-unique upload I can get the argument and resolve it against the > working directory in the file system view; but this seems unnecessarily > complex and does not for for unique uploads (STOU) because the random file > name is not available. > Browsing the code I can see the file observer stuff, but these are non-public > APIs and there can be only one observer at a time whilst I can have many > independent Ftplets implementing the onUpload APIs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-358) Embed Apache FtpServer into Geronimo
[ https://issues.apache.org/jira/browse/FTPSERVER-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12849119#action_12849119 ] David Latorre commented on FTPSERVER-358: - We would be glad to receive your contributions in this issue. Still, having FTPServer deploy as a JCAspec-compliant component doesn't look trivial, right? Just for consistency, can you point to the section in the spec that forbids Secker Sockets? > Embed Apache FtpServer into Geronimo > > > Key: FTPSERVER-358 > URL: https://issues.apache.org/jira/browse/FTPSERVER-358 > Project: FtpServer > Issue Type: New Feature >Reporter: Jürgen Weber > > It should be possible to deploy Apache FtpServer as JCA resource adapter into > a JEE application server like Geronimo. > The suggested way of Embedding FtpServer is a violation of the JEE spec > because FtpServer opens server sockets. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-357) Implement IP Filtering based on black or white list
[ https://issues.apache.org/jira/browse/FTPSERVER-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12847289#action_12847289 ] David Latorre commented on FTPSERVER-357: - About the metho names... We are keeping the getBlockedSubnets() getBlockedAddresses() methods right? I don't know if we choose a better name for these methods as they are a bit misleading ( I can't think of any though and its one of our internal classes so whatever). I don't really know what are the capabilities that a Whitelist/blacklist solution should offer but I have some doubts: - Is it likely that blacklist & whitelist can be used at the same time? For example, we have some range of subnets allowed but there is a specific host which is trying to break into FTPServer or flooding it with connections: an user FTPLet might detect this and try to include that host to the blacklist. I think spam filters define "whitelist" as a list of addresses that are never rejected rather than "the only addresses that are allowed to connect to the server" - is that an useful feature for us? - Should we extend the black/white listing to the USER level? So, user A can only connect from X.X.X.X whereas user B can connect from Y.Y.Y.Y or Y.Y.Y.Z I find this most useful in our own case at my company where different users means different customers. > Implement IP Filtering based on black or white list > --- > > Key: FTPSERVER-357 > URL: https://issues.apache.org/jira/browse/FTPSERVER-357 > Project: FtpServer > Issue Type: New Feature > Components: Core >Reporter: Sai Pullabhotla > Fix For: 1.1.0 > > Attachments: ftpserver-ipfilter.patch > > > Create a new IP Filter based on black or white list to deny or allow incoming > client connections. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DIRMINA-773) org.apache.mina.filter.firewall.Subnet should consider 0.0.0.0/0 as a subnet that contains 'all the ipv4 addresses'
org.apache.mina.filter.firewall.Subnet should consider 0.0.0.0/0 as a subnet that contains 'all the ipv4 addresses' Key: DIRMINA-773 URL: https://issues.apache.org/jira/browse/DIRMINA-773 Project: MINA Issue Type: Improvement Components: Filter Affects Versions: 2.0.0-RC1 Reporter: David Latorre One of our users when trying to implement a WhilteListFilter found the problem that there is no way to declare a subnet that would comprise any ip address. As discussed in dev-mailing list, a 0.0.0.0/0 subnet should return always true for Subnet.inSubnet( any_ipv4_address) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-349) WhiteList
[ https://issues.apache.org/jira/browse/FTPSERVER-349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12842621#action_12842621 ] David Latorre commented on FTPSERVER-349: - Hello Devnull, When i first revised your patch I noticed this problem. I considered some possibilities you haven't mentioned: -1. In the method that adds the subnets/ips to the WhiteListFilter ( updateWhitelistFilter(), right?) we can remove the filter from the chain if we have an empty subnet list. This would work but I'm concerned that ftpserver users may want to use WhiteListFilter when it is not in the chain. -2. Explictly check for the address 0.0.0.0/0 and consider it to mean "all addresses allowed". If we move the WhiteListFilter to MINA-core, it might be worth discussing there how to signal that "all addresses are allowed". What do you think, Niklas? > WhiteList > - > > Key: FTPSERVER-349 > URL: https://issues.apache.org/jira/browse/FTPSERVER-349 > Project: FtpServer > Issue Type: Improvement > Components: Server >Affects Versions: 1.0.3 >Reporter: DevNull43 >Priority: Trivial > Fix For: 1.1.0 > > Attachments: WhiteList.txt > > > WhiteList filer > Restricting access to FTP based on a WhiteList > BlackList -> Allow all, Deny some. > WhiteList -> Deny all, Allow some. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-678) NioProcessor 100% CPU usage on Linux (epoll selector bug)
[ https://issues.apache.org/jira/browse/DIRMINA-678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12831361#action_12831361 ] David Latorre commented on DIRMINA-678: --- Hello Serge, I haven't paid much attention to this issue but as you can see from the code comments Emmanuel is willing to revert the change if neccessary. Still, not all our users are going to upgrade Sun JDK 1.6_18 so it might be interesting that you provided more details on the failures you are having so we can provide a solution for all the potential MINA users - this is ,of course, if the issue is 'easily fixable', otherwise updating to a non-buggy JDK version is the way to go. > NioProcessor 100% CPU usage on Linux (epoll selector bug) > - > > Key: DIRMINA-678 > URL: https://issues.apache.org/jira/browse/DIRMINA-678 > Project: MINA > Issue Type: Bug > Components: Core >Affects Versions: 2.0.0-M4 > Environment: CentOS 5.x, 32/64-bit, 32/64-bit Sun JDK 1.6.0_12, also > _11/_10/_09 and Sun JDK 1.7.0 b50, Kernel 2.6.18-92.1.22.el5 and also older > versions, >Reporter: Serge Baranov > Fix For: 2.0.0-RC2 > > Attachments: snap973.png, snap974.png > > > It's the same bug as described at http://jira.codehaus.org/browse/JETTY-937 , > but affecting MINA in the very similar way. > NioProcessor threads start to eat 100% resources per CPU. After 10-30 minutes > of running depending on the load (sometimes after several hours) one of the > NioProcessor starts to consume all the available CPU resources probably > spinning in the epoll select loop. Later, more threads can be affected by the > same issue, thus 100% loading all the available CPU cores. > Sample trace: > NioProcessor-10 [RUNNABLE] CPU time: 5:15 > sun.nio.ch.EPollArrayWrapper.epollWait(long, int, long, int) > sun.nio.ch.EPollArrayWrapper.poll(long) > sun.nio.ch.EPollSelectorImpl.doSelect(long) > sun.nio.ch.SelectorImpl.lockAndDoSelect(long) > sun.nio.ch.SelectorImpl.select(long) > org.apache.mina.transport.socket.nio.NioProcessor.select(long) > org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run() > org.apache.mina.util.NamePreservingRunnable.run() > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor$Worker) > java.util.concurrent.ThreadPoolExecutor$Worker.run() > java.lang.Thread.run() > It seems to affect any NIO based Java server applications running in the > specified environment. > Some projects provide workarounds for similar JDK bugs, probably MINA can > also think about a workaround. > As far as I know, there are at least 3 users who experience this issue with > Jetty and all of them are running CentOS (some distribution default setting > is a trigger?). As for MINA, I'm not aware of similar reports yet. -- 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]
[ 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]
[
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] Commented: (FTPSERVER-287) NLST: Implementation only supports listing files in working directory [patch provided]
[ 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] Closed: (FTPSERVER-307) SymbolicLinkTest fails in Windows machines.
[ https://issues.apache.org/jira/browse/FTPSERVER-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre closed FTPSERVER-307. --- Resolution: Fixed Fixed in Rev 782091. > SymbolicLinkTest fails in Windows machines. > --- > > Key: FTPSERVER-307 > URL: https://issues.apache.org/jira/browse/FTPSERVER-307 > Project: FtpServer > Issue Type: Bug > Components: Core >Reporter: David Latorre >Assignee: David Latorre > > SymbolicLinkTest.java is throwing an IOException and thus failing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-307) SymbolicLinkTest fails in Windows machines.
SymbolicLinkTest fails in Windows machines. --- Key: FTPSERVER-307 URL: https://issues.apache.org/jira/browse/FTPSERVER-307 Project: FtpServer Issue Type: Bug Components: Core Reporter: David Latorre Assignee: David Latorre SymbolicLinkTest.java is throwing an IOException and thus failing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FTPSERVER-300) Create an extensible getPassiveExternalAddress() method in PASV command so ftp integrators can define additional ways to obtain their 'external passive address'.
[ https://issues.apache.org/jira/browse/FTPSERVER-300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre closed FTPSERVER-300. --- Added javadoc and a test case. > Create an extensible getPassiveExternalAddress() method in PASV command so > ftp integrators can define additional ways to obtain their 'external passive > address'. > -- > > Key: FTPSERVER-300 > URL: https://issues.apache.org/jira/browse/FTPSERVER-300 > Project: FtpServer > Issue Type: Improvement >Reporter: David Latorre >Assignee: David Latorre > Fix For: 1.0.2 > > > PASV command will return the server's ip address and a port number to the > client in order for this to initiate a new data connection. > In the case we are behind a NAT proxy, we need to figure out what is the IP > address the client is actually connecting to. For this, ftpserver provides a > configuration option to establish the IP address which will be returned > after a PASV command is sent. > This method will work in a number of cases but it is not enough in several > others , e.g., if the server has a dynamic ip or if different users see > different ips for the same machine ( which can be the case, it is my case > actually) . > So we might add a protected method getExternalPassiveAddress() in PASV > command implementation so the external ip guessing can be customized as > needed by extenders. Otherwise, the whole Passive method should be > re-implemented. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FTPSERVER-306) some clients won't transform NEW LINE characters to \r\n when sending in ASCII mode so after sending a file the new lines will be gone.
[ https://issues.apache.org/jira/browse/FTPSERVER-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre resolved FTPSERVER-306. - Resolution: Fixed I think it's fixed now, but it might not work with other line separators than CRLF or LF ... > some clients won't transform NEW LINE characters to \r\n when sending in > ASCII mode so after sending a file the new lines will be gone. > - > > Key: FTPSERVER-306 > URL: https://issues.apache.org/jira/browse/FTPSERVER-306 > Project: FtpServer > Issue Type: Improvement >Reporter: David Latorre > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-306) some clients won't transform NEW LINE characters to \r\n when sending in ASCII mode so after sending a file the new lines will be gone.
[ https://issues.apache.org/jira/browse/FTPSERVER-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12712889#action_12712889 ] David Latorre commented on FTPSERVER-306: - Sending a file with \n separated lines in ASCII mode with FileZilla for windows will result in a file with no new lines: when FtpServer receives a file in ASCII mode our current code replaces \r for \r\n and ignores \n, but since it seems FileZilla doesn't transform new lines to \r\n we will never find a \r and the new line characters will be silently ignored. This is a bug in Filezilla (Might be because im sending "Unix" files from windows) but I doubt every other client is performing this transformation. So, when we find a \n we should check if last character was \r and otherwise insert the new line sequence. > some clients won't transform NEW LINE characters to \r\n when sending in > ASCII mode so after sending a file the new lines will be gone. > - > > Key: FTPSERVER-306 > URL: https://issues.apache.org/jira/browse/FTPSERVER-306 > Project: FtpServer > Issue Type: Improvement >Reporter: David Latorre > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-306) some clients won't transform NEW LINE characters to \r\n when sending in ASCII mode so after sending a file the new lines will be gone.
some clients won't transform NEW LINE characters to \r\n when sending in ASCII mode so after sending a file the new lines will be gone. - Key: FTPSERVER-306 URL: https://issues.apache.org/jira/browse/FTPSERVER-306 Project: FtpServer Issue Type: Improvement Reporter: David Latorre -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FTPSERVER-303) Passive data connection stuck in CLOSE_WAIT.
[ https://issues.apache.org/jira/browse/FTPSERVER-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre closed FTPSERVER-303. --- Resolution: Fixed Fix Version/s: 1.0.0 1.0.1 1.0.2 Committed to 1.0.0, 1.0.1 and trunk. I'm sorry for the delay! Alberto, can you proceed to test the fix and see if it's solving your problem? In my tests the connections are immediately closed so you should expect no issues here though. > Passive data connection stuck in CLOSE_WAIT. > > > Key: FTPSERVER-303 > URL: https://issues.apache.org/jira/browse/FTPSERVER-303 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0.0, 1.0.1 >Reporter: Alberto Vazquez >Assignee: David Latorre > Fix For: 1.0.2, 1.0.1, 1.0.0 > > > We are using a week old snapshot from Ftpserver (it seems a bit newer than > the 1.0.1 freeze). One of our clients reported that the data connection was > being kept open for a long time ... They are using a propietary client its > name I cannot remember and it was an SSL data connection in passive mode. > > After checking this using a windows Filezilla client and a Linux server > running ftpserver (on top of Sun Java Application Server 9) we noticed that > the FTP Server had several sockets in CLOSE_WAIT state. At the client side, > the state was FIN_WAIT_2. > To my mind , this could be related with the Socket leaking bug that was > previously reported with SSL passive connections or its workaround although > it might be SJAS fault or-who-knows. Since we don't have a linux machine > available for testing I don't know what the real problem is. > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (FTPSERVER-303) Passive data connection stuck in CLOSE_WAIT.
[ https://issues.apache.org/jira/browse/FTPSERVER-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre reassigned FTPSERVER-303: --- Assignee: David Latorre > Passive data connection stuck in CLOSE_WAIT. > > > Key: FTPSERVER-303 > URL: https://issues.apache.org/jira/browse/FTPSERVER-303 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0.0, 1.0.1 >Reporter: Alberto Vazquez >Assignee: David Latorre > > We are using a week old snapshot from Ftpserver (it seems a bit newer than > the 1.0.1 freeze). One of our clients reported that the data connection was > being kept open for a long time ... They are using a propietary client its > name I cannot remember and it was an SSL data connection in passive mode. > > After checking this using a windows Filezilla client and a Linux server > running ftpserver (on top of Sun Java Application Server 9) we noticed that > the FTP Server had several sockets in CLOSE_WAIT state. At the client side, > the state was FIN_WAIT_2. > To my mind , this could be related with the Socket leaking bug that was > previously reported with SSL passive connections or its workaround although > it might be SJAS fault or-who-knows. Since we don't have a linux machine > available for testing I don't know what the real problem is. > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-303) Passive data connection stuck in CLOSE_WAIT.
[ https://issues.apache.org/jira/browse/FTPSERVER-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711079#action_12711079 ] David Latorre commented on FTPSERVER-303: - Bug confirmed ... It seems that the problem is in IoDataConnectionFactory.createDataSocket() , when using SSL passive mode we had to do some modifications to workaround a JVM bug and now we are wrapping a regular socket with a sslSocket: SSLSocket sslSocket = (SSLSocket) ssocketFactory .createSocket(serverSocket, serverSocket .getInetAddress().getHostName(), serverSocket.getPort(), false); The last parameter is a boolean "autoclose" (close the underlying socket when this socket is closed) it seems that we want this to true, and changing the value to true gets rid of the problem. Niklas, can you foresee any other problems if we changed autoclose to true ? > Passive data connection stuck in CLOSE_WAIT. > > > Key: FTPSERVER-303 > URL: https://issues.apache.org/jira/browse/FTPSERVER-303 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0.0, 1.0.1 >Reporter: Alberto Vazquez > > We are using a week old snapshot from Ftpserver (it seems a bit newer than > the 1.0.1 freeze). One of our clients reported that the data connection was > being kept open for a long time ... They are using a propietary client its > name I cannot remember and it was an SSL data connection in passive mode. > > After checking this using a windows Filezilla client and a Linux server > running ftpserver (on top of Sun Java Application Server 9) we noticed that > the FTP Server had several sockets in CLOSE_WAIT state. At the client side, > the state was FIN_WAIT_2. > To my mind , this could be related with the Socket leaking bug that was > previously reported with SSL passive connections or its workaround although > it might be SJAS fault or-who-knows. Since we don't have a linux machine > available for testing I don't know what the real problem is. > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FTPSERVER-300) Create an extensible getPassiveExternalAddress() method in PASV command so ftp integrators can define additional ways to obtain their 'external passive address'.
[ https://issues.apache.org/jira/browse/FTPSERVER-300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre resolved FTPSERVER-300. - Resolution: Fixed Fix Version/s: 1.0.2 Are you ok with this, Niklas? We are exporting FtpIoSession but FtpSession doesn't have access to the Listener information... would that cause any trouble in the case of OSGI? Sorry, I didn't think about that possibility until I had already committed. > Create an extensible getPassiveExternalAddress() method in PASV command so > ftp integrators can define additional ways to obtain their 'external passive > address'. > -- > > Key: FTPSERVER-300 > URL: https://issues.apache.org/jira/browse/FTPSERVER-300 > Project: FtpServer > Issue Type: Improvement >Reporter: David Latorre >Assignee: David Latorre > Fix For: 1.0.2 > > > PASV command will return the server's ip address and a port number to the > client in order for this to initiate a new data connection. > In the case we are behind a NAT proxy, we need to figure out what is the IP > address the client is actually connecting to. For this, ftpserver provides a > configuration option to establish the IP address which will be returned > after a PASV command is sent. > This method will work in a number of cases but it is not enough in several > others , e.g., if the server has a dynamic ip or if different users see > different ips for the same machine ( which can be the case, it is my case > actually) . > So we might add a protected method getExternalPassiveAddress() in PASV > command implementation so the external ip guessing can be customized as > needed by extenders. Otherwise, the whole Passive method should be > re-implemented. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (FTPSERVER-300) Create an extensible getPassiveExternalAddress() method in PASV command so ftp integrators can define additional ways to obtain their 'external passive address'.
[ https://issues.apache.org/jira/browse/FTPSERVER-300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre reassigned FTPSERVER-300: --- Assignee: David Latorre > Create an extensible getPassiveExternalAddress() method in PASV command so > ftp integrators can define additional ways to obtain their 'external passive > address'. > -- > > Key: FTPSERVER-300 > URL: https://issues.apache.org/jira/browse/FTPSERVER-300 > Project: FtpServer > Issue Type: Improvement >Reporter: David Latorre >Assignee: David Latorre > > PASV command will return the server's ip address and a port number to the > client in order for this to initiate a new data connection. > In the case we are behind a NAT proxy, we need to figure out what is the IP > address the client is actually connecting to. For this, ftpserver provides a > configuration option to establish the IP address which will be returned > after a PASV command is sent. > This method will work in a number of cases but it is not enough in several > others , e.g., if the server has a dynamic ip or if different users see > different ips for the same machine ( which can be the case, it is my case > actually) . > So we might add a protected method getExternalPassiveAddress() in PASV > command implementation so the external ip guessing can be customized as > needed by extenders. Otherwise, the whole Passive method should be > re-implemented. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-300) Create an extensible getPassiveExternalAddress() method in PASV command so ftp integrators can define additional ways to obtain their 'external passive address'.
Create an extensible getPassiveExternalAddress() method in PASV command so ftp integrators can define additional ways to obtain their 'external passive address'. -- Key: FTPSERVER-300 URL: https://issues.apache.org/jira/browse/FTPSERVER-300 Project: FtpServer Issue Type: Improvement Reporter: David Latorre PASV command will return the server's ip address and a port number to the client in order for this to initiate a new data connection. In the case we are behind a NAT proxy, we need to figure out what is the IP address the client is actually connecting to. For this, ftpserver provides a configuration option to establish the IP address which will be returned after a PASV command is sent. This method will work in a number of cases but it is not enough in several others , e.g., if the server has a dynamic ip or if different users see different ips for the same machine ( which can be the case, it is my case actually) . So we might add a protected method getExternalPassiveAddress() in PASV command implementation so the external ip guessing can be customized as needed by extenders. Otherwise, the whole Passive method should be re-implemented. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-289) Implement locking mechanism for files.
Implement locking mechanism for files. -- Key: FTPSERVER-289 URL: https://issues.apache.org/jira/browse/FTPSERVER-289 Project: FtpServer Issue Type: New Feature Components: Core Affects Versions: 1.0.0 Reporter: David Latorre Fix For: WISHLIST In order to solve FTPSERVER-288 , this is, to prevent the possibility of race conditions in STOU command ( it is possible that non-unique filenames be generated with the current implementation) we would eventually need that there was some file locking mechanism which might be a mechanism to keep track of in-use files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-288) Race condition in STOU getUniqueFile
[ https://issues.apache.org/jira/browse/FTPSERVER-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre updated FTPSERVER-288: Summary: Race condition in STOU getUniqueFile (was: Race in condition in STOU getUniqueFile ) > Race condition in STOU getUniqueFile > -- > > Key: FTPSERVER-288 > URL: https://issues.apache.org/jira/browse/FTPSERVER-288 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0.0-M1, 1.0.0-M2, 1.0.0-M3, 1.0.0-M4, 1.0.0-RC1, > 1.0.0-RC2, 1.0.0, 1.0.1, 1.1 >Reporter: David Latorre > > Sai reports the following bug: > 2. getUniqueFile in STOU command may need to be synchronized. Even if we > synchronize it, there is no gurantee that two different FTP sessions get the > same file as we do not create the file in this method. Perhaps, we should use > File.createTempFile() method to do this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-288) Race in condition in STOU getUniqueFile
Race in condition in STOU getUniqueFile - Key: FTPSERVER-288 URL: https://issues.apache.org/jira/browse/FTPSERVER-288 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0.0, 1.0.0-RC2, 1.0.0-RC1, 1.0.0-M4, 1.0.0-M3, 1.0.0-M2, 1.0.0-M1, 1.0.1, 1.1 Reporter: David Latorre Sai reports the following bug: 2. getUniqueFile in STOU command may need to be synchronized. Even if we synchronize it, there is no gurantee that two different FTP sessions get the same file as we do not create the file in this method. Perhaps, we should use File.createTempFile() method to do this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-253) Enhance the Ftplet.afterCommand to provide more information about the result of command execution
[ https://issues.apache.org/jira/browse/FTPSERVER-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12696179#action_12696179 ] David Latorre commented on FTPSERVER-253: - Wow Sai :-) Are you subscribed to the developers mailing list? So we can move the discussion there. I hadn't thought much about these changes myself but your work looks pretty good. The only thing I don't quite get is why we would use FTPFile.getPhysicalFile ... Since it returns an Object, the coder developing the FTPLet should know which 'PhysicalFile' object (s)he is using. This would mean in most situations that they know which FTPFile implementation they're using and hence, they could use casting to their appropriate type. And I guess it's possible to have an implementation of FTPFile that doesn't use a "PhysicalFile" object ... So what's your use case for this addition? I'm so tired i can't clearly think... Another problem we have is that it is becoming quite difficult to develop pluggable components (be it an UserManager ,a Command or a ftplet) with only the API documentation. How would a user know which types of FTPReply he should use if overwriting a command? - I don't have a solution for this at all. It's just something we could think about. Agree we should add a bug report for getUniqueFile(), using createTempFile would be simpler but it is probably better to generate an unique filename and check for permission before creating the actual file (so all these should be under a static lock) ; although of course checking only parent directory permissions we are good to go right now. > Enhance the Ftplet.afterCommand to provide more information about the result > of command execution > - > > Key: FTPSERVER-253 > URL: https://issues.apache.org/jira/browse/FTPSERVER-253 > Project: FtpServer > Issue Type: New Feature > Components: Core, Ftplets >Reporter: Sai Pullabhotla > Fix For: 1.1 > > Attachments: FTPSERVER-253_Patch.txt > > > It would be nice to enhance the afterCommand method in the Ftplet to provide > additional details about the result of command execution. Currently the > afterCommand method of an Ftplet is called back with the following parameters > - > FtpSession, FtpRequest and FtpReply. The FtpReply parameter contains only the > reply code and the reply string that was sent. The Ftplets may want to know a > little more information on what exactly happened to the command that was > executed. For example, the afterCommand for RNTO command might want to know > the from file, the to file and if the command was successful or not. > More information on this can be found at > http://www.mail-archive.com/ftpserver-us...@mina.apache.org/msg00512.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FTPSERVER-286) Hey, how can i add muti-language support? such as Japanese!
[ https://issues.apache.org/jira/browse/FTPSERVER-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre closed FTPSERVER-286. --- Resolution: Duplicate This issue is a duplicate FTPSERVER-283. Currently you must use a UTF-8 compatible client as mandated by the Spec: an example is FileZilla client or JMethod's JFTP. > Hey, how can i add muti-language support? such as Japanese! > --- > > Key: FTPSERVER-286 > URL: https://issues.apache.org/jira/browse/FTPSERVER-286 > Project: FtpServer > Issue Type: Bug >Affects Versions: 1.0.0 > Environment: linux / Win XP >Reporter: dongyajun > > When i put a file that named after Japanese, throws following exception : > 2009-04-03 15:26:21,234 INFO > org.apache.ftpserver.listener.nio.FtpLoggingFilter: RECEIVED: TYPE I > 2009-04-03 15:26:21,234 WARN > org.apache.ftpserver.listener.nio.FtpLoggingFilter: SENT: 200 Command TYPE > okay. > 2009-04-03 15:26:21,234 INFO > org.apache.ftpserver.listener.nio.FtpLoggingFilter: RECEIVED: PASV > 2009-04-03 15:26:21,250 WARN > org.apache.ftpserver.listener.nio.FtpLoggingFilter: SENT: 227 Entering > Passive Mode (192,168,3,11,4,179) > 2009-04-03 15:26:21,250 ERROR > org.apache.ftpserver.listener.nio.FtpLoggingFilter: EXCEPTION : > org.apache.mina.filter.codec.ProtocolDecoderException: > java.nio.charset.MalformedInputException: Input length = 2 (Hexdump: E3 82 B9 > E7 89 88 20 28 41 6C 70 68 61 2D 52 4F 4D 76 33 E8 A3 9C E4 BF AE E6 B8 3F 6D > 64 66 2B 6D 64 73 29 2E 72 61 72 0D 0A) > at > org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:234) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:48) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:802) > at > org.apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:59) > at org.apache.mina.core.session.IoEvent.run(IoEvent.java:64) > at > org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.runTask(OrderedThreadPoolExecutor.java:552) > at > org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.runTasks(OrderedThreadPoolExecutor.java:544) > at > org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.run(OrderedThreadPoolExecutor.java:488) > at java.lang.Thread.run(Unknown Source) > Caused by: java.nio.charset.MalformedInputException: Input length = 2 > at java.nio.charset.CoderResult.throwException(Unknown Source) > at > org.apache.mina.core.buffer.AbstractIoBuffer.getString(AbstractIoBuffer.java:1130) > at > org.apache.mina.filter.codec.textline.TextLineDecoder.decodeAuto(TextLineDecoder.java:207) > at > org.apache.mina.filter.codec.textline.TextLineDecoder.decode(TextLineDecoder.java:138) > at > org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:224) > ... 9 more > 2009-04-03 15:26:21,250 ERROR org.apache.ftpserver.impl.DefaultFtpHandler: > Exception caught, closing session > org.apache.mina.filter.codec.ProtocolDecoderException: > java.nio.charset.MalformedInputException: Input length = 2 (Hexdump: E3 82 B9 > E7 89 88 20 28 41 6C 70 68 61 2D 52 4F 4D 76 33 E8 A3 9C E4 BF AE E6 B8 3F 6D > 64 66 2B 6D 64 73 29 2E 72 61 72 0D 0A) > at > org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:234) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:48) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:802) > at > org.apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:59) > at org.apache.mina.core.session.IoEvent.run(IoEvent.java:64) > at > org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.runTask(OrderedThreadPoolExecutor.java:552) > at > org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.runTasks(OrderedThreadPoolExecutor.java:544) > at > org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.run(OrderedThreadPoolExecutor.java:488) > at java.lang.Thread.run(Unknown Source) > Caused by: java.nio.charset.MalformedInputException: Input length = 2 > at java.nio.charset.CoderResult.throwException(Unknown Source) > at > org.apache.mina.core.buffer.AbstractIoBuffer.getString(AbstractIoBuffer.java:1130) > at > org.ap
[jira] Commented: (FTPSERVER-284) Service fails to start
[ https://issues.apache.org/jira/browse/FTPSERVER-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12694956#action_12694956 ] David Latorre commented on FTPSERVER-284: - The only difference I see with my config is that I have JAVA_HOME set, try setting it to a suitable JDK (5/6). Other than that, you may want to remove apache/lib directory but it shouldn't be in the classpath ( I don't know what your CLASSPATH variable looks like anyway). > Service fails to start > -- > > Key: FTPSERVER-284 > URL: https://issues.apache.org/jira/browse/FTPSERVER-284 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0.0 > Environment: Windows XP & Windows Vista >Reporter: Eyal Safran >Priority: Blocker > Attachments: FileList.txt, jakarta_service_20090402.log > > > After installing the FtpServer as a service, When trying to run the service, > it won't start and the log shows: > [2009-04-01 12:11:00] [info] Service ftpd name Apache FtpServer > [2009-04-01 12:11:00] [info] Service ftpd installed > [2009-04-01 12:11:00] [info] Procrun finished. > [2009-04-01 12:11:00] [info] Updating service... > [2009-04-01 12:11:01] [info] Service ftpd updated > [2009-04-01 12:11:01] [info] Update service finished. > [2009-04-01 12:11:01] [info] Procrun finished. > [2009-04-01 12:11:28] [info] Running Service... > [2009-04-01 12:11:28] [info] Starting service... > [2009-04-01 12:11:28] [458 javajni.c] [error] FindClass > org/apache/ftpserver/main/Daemon failed > [2009-04-01 12:11:28] [958 prunsrv.c] [error] Failed loading main > org/apache/ftpserver/main/Daemon class > D:\apache\common\classes;D:\apache\common\lib\aopalliance-1.0.jar;D:\apache\common\lib\ftplet-api-1.0.0.jar;D:\apache\common\lib\ftpserver-core-1.0.0.jar;D:\apache\common\lib\jcl-over-slf4j-1.5.2.jar;D:\apache\common\lib\log4j-1.2.14.jar;D:\apache\common\lib\mina-core-2.0.0-M4.jar;D:\apache\common\lib\slf4j-api-1.5.2.jar;D:\apache\common\lib\slf4j-log4j12-1.5.2.jar;D:\apache\common\lib\spring-beans-2.5.5.jar;D:\apache\common\lib\spring-context-2.5.5.jar;D:\apache\common\lib\spring-core-2.5.5.jar > [2009-04-01 12:11:28] [1202 prunsrv.c] [error] ServiceStart returned 3 > [2009-04-01 12:11:28] [info] Run service finished. > [2009-04-01 12:11:28] [info] Procrun finished. > --- > Installation procedure: > 1) I've extracted the content of the ftpserver-1.0.0.zip file in drive D: > 2) I've renamed the folder to: "Apache" (at first i tried without renaming, > and when it didn't work I googled for a solution and saw this link, that's > why I renamed it, to make the path shorter): > http://mail-archives.apache.org/mod_mbox/mina-ftpserver-users/200810.mbox/%3cd10461fc0810041030t64e0ad02s259ea4df51213...@mail.gmail.com%3e > 3) I opened command prompt > 4) changed directory to: d:\Apache > 5) typed: > D:\apache>bin\service.bat install ftpd res\conf\ftpd-typical.xml > 6) got the result: > Installing the service 'ftpd' ... > Using FTPD_HOME:D:\apache > Using JAVA_HOME: > Using JVM: auto > start > start;res\conf\ftpd-typical.xml > start;res\conf\ftpd-typical.xml > The service 'ftpd' has been installed. > 7) the service did not start > 8) I went to services and tried to start the service, and the service did not > start. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-284) Service fails to start
[ https://issues.apache.org/jira/browse/FTPSERVER-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12694925#action_12694925 ] David Latorre commented on FTPSERVER-284: - Hello Eyal, I've followed your steps ( using net start ftpd to start the service) but building ftpserver myself with provided maven files and the service is working correctly. Can you attach the log file in res/log/ to check if there is any hint there of what's happening? > Service fails to start > -- > > Key: FTPSERVER-284 > URL: https://issues.apache.org/jira/browse/FTPSERVER-284 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0.0 > Environment: Windows XP & Windows Vista >Reporter: Eyal Safran >Priority: Blocker > > After installing the FtpServer as a service, When trying to run the service, > it won't start and the log shows: > [2009-04-01 12:11:00] [info] Service ftpd name Apache FtpServer > [2009-04-01 12:11:00] [info] Service ftpd installed > [2009-04-01 12:11:00] [info] Procrun finished. > [2009-04-01 12:11:00] [info] Updating service... > [2009-04-01 12:11:01] [info] Service ftpd updated > [2009-04-01 12:11:01] [info] Update service finished. > [2009-04-01 12:11:01] [info] Procrun finished. > [2009-04-01 12:11:28] [info] Running Service... > [2009-04-01 12:11:28] [info] Starting service... > [2009-04-01 12:11:28] [458 javajni.c] [error] FindClass > org/apache/ftpserver/main/Daemon failed > [2009-04-01 12:11:28] [958 prunsrv.c] [error] Failed loading main > org/apache/ftpserver/main/Daemon class > D:\apache\common\classes;D:\apache\common\lib\aopalliance-1.0.jar;D:\apache\common\lib\ftplet-api-1.0.0.jar;D:\apache\common\lib\ftpserver-core-1.0.0.jar;D:\apache\common\lib\jcl-over-slf4j-1.5.2.jar;D:\apache\common\lib\log4j-1.2.14.jar;D:\apache\common\lib\mina-core-2.0.0-M4.jar;D:\apache\common\lib\slf4j-api-1.5.2.jar;D:\apache\common\lib\slf4j-log4j12-1.5.2.jar;D:\apache\common\lib\spring-beans-2.5.5.jar;D:\apache\common\lib\spring-context-2.5.5.jar;D:\apache\common\lib\spring-core-2.5.5.jar > [2009-04-01 12:11:28] [1202 prunsrv.c] [error] ServiceStart returned 3 > [2009-04-01 12:11:28] [info] Run service finished. > [2009-04-01 12:11:28] [info] Procrun finished. > --- > Installation procedure: > 1) I've extracted the content of the ftpserver-1.0.0.zip file in drive D: > 2) I've renamed the folder to: "Apache" (at first i tried without renaming, > and when it didn't work I googled for a solution and saw this link, that's > why I renamed it, to make the path shorter): > http://mail-archives.apache.org/mod_mbox/mina-ftpserver-users/200810.mbox/%3cd10461fc0810041030t64e0ad02s259ea4df51213...@mail.gmail.com%3e > 3) I opened command prompt > 4) changed directory to: d:\Apache > 5) typed: > D:\apache>bin\service.bat install ftpd res\conf\ftpd-typical.xml > 6) got the result: > Installing the service 'ftpd' ... > Using FTPD_HOME:D:\apache > Using JAVA_HOME: > Using JVM: auto > start > start;res\conf\ftpd-typical.xml > start;res\conf\ftpd-typical.xml > The service 'ftpd' has been installed. > 7) the service did not start > 8) I went to services and tried to start the service, and the service did not > start. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-285) Managed File Transfer Administrative interface for the FTP Server
[ https://issues.apache.org/jira/browse/FTPSERVER-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12694904#action_12694904 ] David Latorre commented on FTPSERVER-285: - Hello Arun, This is great news, and you're right a management module (I wasn't familiar with the 'MFT' term , cool to know) is something we are lacking. Incubator versions of FtpServer bundled a ftpserver-admin-gui - it has been discontinued and it was far less ambitious than what you're thinking of, but looking at it might be of some help. If you find any difficulty, don't hesitate on requesting any improvement in FtpServer that you may in order to implement this (Actually, for any improvement you can think of :-) ). Besides, you might want to open a thread in the mailing list if you need any ideas or feedback on your work. As an example, my initial approach for this was to use JMX for this, but I'm not so sure right now. > Managed File Transfer Administrative interface for the FTP Server > - > > Key: FTPSERVER-285 > URL: https://issues.apache.org/jira/browse/FTPSERVER-285 > Project: FtpServer > Issue Type: Improvement > Components: AdminGUI > Environment: Not applicable >Reporter: Arun Ram > Original Estimate: 672h > Remaining Estimate: 672h > > Feature: Managed File Transfer Module for the FTP Server > Hello, > I am introducing Apache FtpServer to our enterprise to kick our COTS product > out. > I think managed file transfer module/feature will act as catalyst for any FTP > server product adoption. Now that the API is sold and stable, it is time to > take the product to the next level. I personally think building an intuitive > and simple MFT module will greatly benefit the adoption. > And that's exactly what we are doing. I hope in another couple of months I > can submit my work to you guys. > Here are is the high level Synopsys. > - A admin web interface to the FTP Server so that ftp admin(s) on the fly > make necessary changes to the configurations and to see current transfers > (Ease of use for administrator) > - Allow an employee or user within the enterprise to create an account and > also allow the user to grant necessary privileges to share the file with > others. (Shareability) > - Allow users to setup necessary notification on uploads, downloads, > failures, pending pickup, etc. (Automated transfers) > - Allow users to report on past uploads, downloads, retries, etc. (SOX > compliance!) > Though we can do many other things on this front, I would start here > (Thoughtful reduction) > I am new to this project and I hope I make sense. > Sincerely > --Arun -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-283) Similar bug to FTPServer-61 found using passwords with not-utf8 characters
[ https://issues.apache.org/jira/browse/FTPSERVER-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12694005#action_12694005 ] David Latorre commented on FTPSERVER-283: - The problem with these "standard clients" is that they do not offer any standard way to select which encoding/charset you want to use... If you are paying for them, I would demand that they added UTF-8 support. You can use Filezilla FTP Client which I like better than most of those and supports UTF-8 - and yes, it is free. By the way, according to their own website FlashFXP does support UTF-8 as well, I wonder if all the others are correct ( although at least CuteFTP and voyager don't support UTF-8 as of now). > Similar bug to FTPServer-61 found using passwords with not-utf8 characters > -- > > Key: FTPSERVER-283 > URL: https://issues.apache.org/jira/browse/FTPSERVER-283 > Project: FtpServer > Issue Type: Bug > Components: Core > Environment: AIX 5.3 64 bit >Reporter: salahzar stenvaag > > When specifying a password (PASS command) with special characters like > spanish cedilla we found malformed input exception (see after). > A very similar error has been reported in the past using filenames with > special characters > ==>FTPServer-61<== > but the jira had been dismissed because it was assumed (if I understood > correctly) that client libraries should have specified UTF8 encoding, but if > we are using standard clients it is very difficult... As I saw from > http://ftp-software-review.toptenreviews.com/ only smartftp is able to > specify utf-8 for transferring files... > Wouldn't it be possible to patch ftpserver to handle commands channel without > incurring in such nasty low level exception, and decode them using a list of > configurable encodings (utf8, if it fails ISO-8859-2 and so on)? > Or some tricks to use standard clients letting them specify utf8? > Thanks for any hint you can offer to this. > 2009-03-27 13:36:31,672 [pool-1-thread-1] WARN LoggingFilter - EXCEPTION: > org.apache.mina.filter.codec.ProtocolDecoderException: > java.nio.charset.MalformedInputException: Input length = 2 (Hexdump: 50 41 53 > 53 20 72 46 30 67 40 E7 61 0D 0A) > at > org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:180) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:414) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:49) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:832) > at > org.apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:60) > at org.apache.mina.core.session.IoEvent.run(IoEvent.java:64) > at > org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.runTask(OrderedThreadPoolExecutor.java:551) > at > org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.runTasks(OrderedThreadPoolExecutor.java:543) > at > org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.run(OrderedThreadPoolExecutor.java:487) > at java.lang.Thread.run(Thread.java:810) > Caused by: > java.nio.charset.MalformedInputException: Input length = 2 > at java.nio.charset.CoderResult.throwException(CoderResult.java:283) > at > org.apache.mina.core.buffer.AbstractIoBuffer.getString(AbstractIoBuffer.java:1122) > at > org.apache.mina.filter.codec.textline.TextLineDecoder.decodeAuto(TextLineDecoder.java:207) > at > org.apache.mina.filter.codec.textline.TextLineDecoder.decode(TextLineDecoder.java:138) > at > org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:170) > ... 9 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FTPSERVER-274) Use Wildcard-Generics in API where possible and plausible
[ https://issues.apache.org/jira/browse/FTPSERVER-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre closed FTPSERVER-274. --- Resolution: Fixed Thanks for your report and reviews, Steve! > Use Wildcard-Generics in API where possible and plausible > - > > Key: FTPSERVER-274 > URL: https://issues.apache.org/jira/browse/FTPSERVER-274 > Project: FtpServer > Issue Type: Improvement >Affects Versions: 1.0.0-RC2 >Reporter: Steve Ulrich >Assignee: David Latorre > Fix For: 1.1 > > Attachments: ftpserver.patch > > > Currently the API doesn't make use of wildcard generic types. > Example FtpFile: > public abstract List listFiles(); > The used generic for the return type prevents users from returning lists with > their own type (ie: List). > A change to: > public abstract List listFiles(); > Would allow this without any costs (or I just can't see them *g*) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-274) Use Wildcard-Generics in API where possible and plausible
[ https://issues.apache.org/jira/browse/FTPSERVER-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12680271#action_12680271 ] David Latorre commented on FTPSERVER-274: - Fixed in rev. #751827 - Can you test it, Steve? > Use Wildcard-Generics in API where possible and plausible > - > > Key: FTPSERVER-274 > URL: https://issues.apache.org/jira/browse/FTPSERVER-274 > Project: FtpServer > Issue Type: Improvement >Affects Versions: 1.0.0-RC2 >Reporter: Steve Ulrich >Assignee: David Latorre > Fix For: 1.1 > > Attachments: ftpserver.patch > > > Currently the API doesn't make use of wildcard generic types. > Example FtpFile: > public abstract List listFiles(); > The used generic for the return type prevents users from returning lists with > their own type (ie: List). > A change to: > public abstract List listFiles(); > Would allow this without any costs (or I just can't see them *g*) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-274) Use Wildcard-Generics in API where possible and plausible
[ https://issues.apache.org/jira/browse/FTPSERVER-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre updated FTPSERVER-274: Attachment: ftpserver.patch I hadn't noticed I'm such an ignorant when it comes to java Generics. Is this patch a step towards the correct solution? > Use Wildcard-Generics in API where possible and plausible > - > > Key: FTPSERVER-274 > URL: https://issues.apache.org/jira/browse/FTPSERVER-274 > Project: FtpServer > Issue Type: Improvement >Affects Versions: 1.0.0-RC2 >Reporter: Steve Ulrich >Assignee: David Latorre > Fix For: 1.1 > > Attachments: ftpserver.patch > > > Currently the API doesn't make use of wildcard generic types. > Example FtpFile: > public abstract List listFiles(); > The used generic for the return type prevents users from returning lists with > their own type (ie: List). > A change to: > public abstract List listFiles(); > Would allow this without any costs (or I just can't see them *g*) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (FTPSERVER-274) Use Wildcard-Generics in API where possible and plausible
[ https://issues.apache.org/jira/browse/FTPSERVER-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre reassigned FTPSERVER-274: --- Assignee: David Latorre > Use Wildcard-Generics in API where possible and plausible > - > > Key: FTPSERVER-274 > URL: https://issues.apache.org/jira/browse/FTPSERVER-274 > Project: FtpServer > Issue Type: Improvement >Affects Versions: 1.0.0-RC2 >Reporter: Steve Ulrich >Assignee: David Latorre > Fix For: 1.1 > > > Currently the API doesn't make use of wildcard generic types. > Example FtpFile: > public abstract List listFiles(); > The used generic for the return type prevents users from returning lists with > their own type (ie: List). > A change to: > public abstract List listFiles(); > Would allow this without any costs (or I just can't see them *g*) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FTPSERVER-270) DBUserManager closeQuitely(Connection con) is private but should be protected as in createConnection.
[ https://issues.apache.org/jira/browse/FTPSERVER-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre closed FTPSERVER-270. --- Resolution: Fixed Fix Version/s: (was: 1.0.0-RC2) Fixed in #737687 > DBUserManager closeQuitely(Connection con) is private but should be > protected as in createConnection. > > > Key: FTPSERVER-270 > URL: https://issues.apache.org/jira/browse/FTPSERVER-270 > Project: FtpServer > Issue Type: Improvement > Components: Core >Reporter: David Latorre > > createConnection in DBUserManager is protected to help reusability but the > matching close method is private. > * It should be possible to check the availability of a Connection with Jdk > 1.6 and so the connection can be reused (Although we do not guarantee it to > work) but it is not now, as we explicitly close the connection. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-270) DBUserManager closeQuitely(Connection con) is private but should be protected as in createConnection.
DBUserManager closeQuitely(Connection con) is private but should be protected as in createConnection. Key: FTPSERVER-270 URL: https://issues.apache.org/jira/browse/FTPSERVER-270 Project: FtpServer Issue Type: Improvement Components: Core Reporter: David Latorre Fix For: 1.0.0-RC2 createConnection in DBUserManager is protected to help reusability but the matching close method is private. * It should be possible to check the availability of a Connection with Jdk 1.6 and so the connection can be reused (Although we do not guarantee it to work) but it is not now, as we explicitly close the connection. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FTPSERVER-260) IOException under high load
[ https://issues.apache.org/jira/browse/FTPSERVER-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre closed FTPSERVER-260. --- Resolution: Invalid Resolution was Invalid not Fixed. > IOException under high load > --- > > Key: FTPSERVER-260 > URL: https://issues.apache.org/jira/browse/FTPSERVER-260 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0.0-M3, 1.0.0-M4 > Environment: Windows XP SP3 >Reporter: John Hearn >Assignee: David Latorre > Attachments: FTP_LOAD_TEST.jmx > > > Under high load I noticed that strange IOExceptions started appearing in the > server log: > java.io.IOException: Se ha anulado una conexión establecida por el software > en su equipo host. > at sun.nio.ch.SocketDispatcher.read0(Native Method) > at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:25) > at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:233) > at sun.nio.ch.IOUtil.read(IOUtil.java:206) > at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:207) > at > org.apache.mina.transport.socket.nio.NioProcessor.read(NioProcessor.java:175) > at > org.apache.mina.transport.socket.nio.NioProcessor.read(NioProcessor.java:42) > at > org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:561) > at > org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:540) > at > org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:532) > at > org.apache.mina.core.polling.AbstractPollingIoProcessor.access$400(AbstractPollingIoProcessor.java:58) > at > org.apache.mina.core.polling.AbstractPollingIoProcessor$Worker.run(AbstractPollingIoProcessor.java:857) > at > org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) > at java.lang.Thread.run(Thread.java:595) > (The message is in spanish because I am in Spain. I believe the exception in > english is "Software caused connection abort" but I may be wrong). > I couldn't find a related bug so as a test I set up a JMeter test rig with a > Thread Group and a basic (passive) FTP Request (user admin, RETR README.txt). > Sure enough when I increase the concurrent threads this error starts > appearing. In fact the error can appear occacionally with a single thread > downloading many files consecutively. > I have tried this with the latest versions of both JMeter and FtpServer and > the error is the same. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (FTPSERVER-260) IOException under high load
[ https://issues.apache.org/jira/browse/FTPSERVER-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre reopened FTPSERVER-260: - Assignee: David Latorre > IOException under high load > --- > > Key: FTPSERVER-260 > URL: https://issues.apache.org/jira/browse/FTPSERVER-260 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0.0-M3, 1.0.0-M4 > Environment: Windows XP SP3 >Reporter: John Hearn >Assignee: David Latorre > Attachments: FTP_LOAD_TEST.jmx > > > Under high load I noticed that strange IOExceptions started appearing in the > server log: > java.io.IOException: Se ha anulado una conexión establecida por el software > en su equipo host. > at sun.nio.ch.SocketDispatcher.read0(Native Method) > at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:25) > at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:233) > at sun.nio.ch.IOUtil.read(IOUtil.java:206) > at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:207) > at > org.apache.mina.transport.socket.nio.NioProcessor.read(NioProcessor.java:175) > at > org.apache.mina.transport.socket.nio.NioProcessor.read(NioProcessor.java:42) > at > org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:561) > at > org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:540) > at > org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:532) > at > org.apache.mina.core.polling.AbstractPollingIoProcessor.access$400(AbstractPollingIoProcessor.java:58) > at > org.apache.mina.core.polling.AbstractPollingIoProcessor$Worker.run(AbstractPollingIoProcessor.java:857) > at > org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) > at java.lang.Thread.run(Thread.java:595) > (The message is in spanish because I am in Spain. I believe the exception in > english is "Software caused connection abort" but I may be wrong). > I couldn't find a related bug so as a test I set up a JMeter test rig with a > Thread Group and a basic (passive) FTP Request (user admin, RETR README.txt). > Sure enough when I increase the concurrent threads this error starts > appearing. In fact the error can appear occacionally with a single thread > downloading many files consecutively. > I have tried this with the latest versions of both JMeter and FtpServer and > the error is the same. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FTPSERVER-260) IOException under high load
[ https://issues.apache.org/jira/browse/FTPSERVER-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre closed FTPSERVER-260. --- Resolution: Fixed I don't think there's much we can do to improve our handling. Maybe something could be done at the Mina level but I don't see that we're suffering any problem now besides the log , ERROR level, entries but since the session is closed the log level can be considered correct. > IOException under high load > --- > > Key: FTPSERVER-260 > URL: https://issues.apache.org/jira/browse/FTPSERVER-260 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0.0-M3, 1.0.0-M4 > Environment: Windows XP SP3 >Reporter: John Hearn > Attachments: FTP_LOAD_TEST.jmx > > > Under high load I noticed that strange IOExceptions started appearing in the > server log: > java.io.IOException: Se ha anulado una conexión establecida por el software > en su equipo host. > at sun.nio.ch.SocketDispatcher.read0(Native Method) > at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:25) > at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:233) > at sun.nio.ch.IOUtil.read(IOUtil.java:206) > at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:207) > at > org.apache.mina.transport.socket.nio.NioProcessor.read(NioProcessor.java:175) > at > org.apache.mina.transport.socket.nio.NioProcessor.read(NioProcessor.java:42) > at > org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:561) > at > org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:540) > at > org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:532) > at > org.apache.mina.core.polling.AbstractPollingIoProcessor.access$400(AbstractPollingIoProcessor.java:58) > at > org.apache.mina.core.polling.AbstractPollingIoProcessor$Worker.run(AbstractPollingIoProcessor.java:857) > at > org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) > at java.lang.Thread.run(Thread.java:595) > (The message is in spanish because I am in Spain. I believe the exception in > english is "Software caused connection abort" but I may be wrong). > I couldn't find a related bug so as a test I set up a JMeter test rig with a > Thread Group and a basic (passive) FTP Request (user admin, RETR README.txt). > Sure enough when I increase the concurrent threads this error starts > appearing. In fact the error can appear occacionally with a single thread > downloading many files consecutively. > I have tried this with the latest versions of both JMeter and FtpServer and > the error is the same. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FTPSERVER-268) SQL statements in provided "distribution/ftpd-full.xml" need to be updated to the latest version in the documentation.
[ https://issues.apache.org/jira/browse/FTPSERVER-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre closed FTPSERVER-268. --- Resolution: Fixed Fix Version/s: 1.0.0-RC2 Assignee: David Latorre Fixed in rev #736002 > SQL statements in provided "distribution/ftpd-full.xml" need to be updated to > the latest version in the documentation. > -- > > Key: FTPSERVER-268 > URL: https://issues.apache.org/jira/browse/FTPSERVER-268 > Project: FtpServer > Issue Type: Bug >Reporter: David Latorre >Assignee: David Latorre >Priority: Minor > Fix For: 1.0.0-RC2 > > > Javi > https://issues.apache.org/jira/browse/FTPSERVER-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > reports that he cannot log-in to FtpServer using the authentication > statement contained in this file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-267) DbUserManager not authenticating with MySQL 5.0.x
[
https://issues.apache.org/jira/browse/FTPSERVER-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12665420#action_12665420
]
David Latorre commented on FTPSERVER-267:
-
New bug report added to update ftpd-full.xml
http://issues.apache.org/jira/browse/FTPSERVER-268
> DbUserManager not authenticating with MySQL 5.0.x
> -
>
> Key: FTPSERVER-267
> URL: https://issues.apache.org/jira/browse/FTPSERVER-267
> Project: FtpServer
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.0.0-RC1
>Reporter: Javi
>Priority: Critical
> Attachments: DbUserManager.java.patch
>
>
> DbUserManager does not set password, failing in the SQL:
> [ INFO] 2009-01-20 01:47:48,322 [admin] [127.0.0.1] SELECT userid from
> FTP_USER WHERE userid='admin' AND userpassword=''
> In order to get it running 2 changes needs to be done:
> 1- Configuration file modify
> SELECT userid from FTP_USER WHERE userid='{userid}' AND
> userpassword='{userpassword}'
> Per this one:
> SELECT userid, userpassword from FTP_USER WHERE
> userid='{userid}' AND userpassword='{userpassword}'
> 2- Modify DbUserManager.authenticate from:
> HashMap map = new HashMap();
> map.put(ATTR_LOGIN, escapeString(user));
> To this one:
> HashMap map = new HashMap();
> map.put(ATTR_LOGIN, escapeString(user));
> map.put(ATTR_PASSWORD,
> getPasswordEncryptor().encrypt(password));
> Notice bug https://issues.apache.org/jira/browse/FTPSERVER-105 is unfixed in
> 1.0.0-RC1 and need to add command "INSERT IGNORE" or MySQL won't run.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-268) SQL statements in provided "distribution/ftpd-full.xml" need to be updated to the latest version in the documentation.
SQL statements in provided "distribution/ftpd-full.xml" need to be updated to the latest version in the documentation. -- Key: FTPSERVER-268 URL: https://issues.apache.org/jira/browse/FTPSERVER-268 Project: FtpServer Issue Type: Bug Reporter: David Latorre Priority: Minor Javi https://issues.apache.org/jira/browse/FTPSERVER-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel reports that he cannot log-in to FtpServer using the authentication statement contained in this file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FTPSERVER-267) DbUserManager not authenticating with MySQL 5.0.x
[
https://issues.apache.org/jira/browse/FTPSERVER-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Latorre closed FTPSERVER-267.
---
Resolution: Invalid
> DbUserManager not authenticating with MySQL 5.0.x
> -
>
> Key: FTPSERVER-267
> URL: https://issues.apache.org/jira/browse/FTPSERVER-267
> Project: FtpServer
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.0.0-RC1
>Reporter: Javi
>Priority: Critical
> Attachments: DbUserManager.java.patch
>
>
> DbUserManager does not set password, failing in the SQL:
> [ INFO] 2009-01-20 01:47:48,322 [admin] [127.0.0.1] SELECT userid from
> FTP_USER WHERE userid='admin' AND userpassword=''
> In order to get it running 2 changes needs to be done:
> 1- Configuration file modify
> SELECT userid from FTP_USER WHERE userid='{userid}' AND
> userpassword='{userpassword}'
> Per this one:
> SELECT userid, userpassword from FTP_USER WHERE
> userid='{userid}' AND userpassword='{userpassword}'
> 2- Modify DbUserManager.authenticate from:
> HashMap map = new HashMap();
> map.put(ATTR_LOGIN, escapeString(user));
> To this one:
> HashMap map = new HashMap();
> map.put(ATTR_LOGIN, escapeString(user));
> map.put(ATTR_PASSWORD,
> getPasswordEncryptor().encrypt(password));
> Notice bug https://issues.apache.org/jira/browse/FTPSERVER-105 is unfixed in
> 1.0.0-RC1 and need to add command "INSERT IGNORE" or MySQL won't run.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-267) DbUserManager not authenticating with MySQL 5.0.x
[
https://issues.apache.org/jira/browse/FTPSERVER-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12665415#action_12665415
]
David Latorre commented on FTPSERVER-267:
-
The documented query string for the authentication statement is this one:
SELECT userpassword from FTP_USER WHERE
userid='{userid}'
It is available at :
http://mina.apache.org/ftpserver/database-user-manager.html be we might need to
check the project so sample XML files have this sentence.
If using that statement you do not need to change the provided DBUserManager.
I'm opening a bug report for a "documentation improvement" and closing this
one. Please feel free to open a new issue if this is not working for you.
> DbUserManager not authenticating with MySQL 5.0.x
> -
>
> Key: FTPSERVER-267
> URL: https://issues.apache.org/jira/browse/FTPSERVER-267
> Project: FtpServer
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.0.0-RC1
>Reporter: Javi
>Priority: Critical
> Attachments: DbUserManager.java.patch
>
>
> DbUserManager does not set password, failing in the SQL:
> [ INFO] 2009-01-20 01:47:48,322 [admin] [127.0.0.1] SELECT userid from
> FTP_USER WHERE userid='admin' AND userpassword=''
> In order to get it running 2 changes needs to be done:
> 1- Configuration file modify
> SELECT userid from FTP_USER WHERE userid='{userid}' AND
> userpassword='{userpassword}'
> Per this one:
> SELECT userid, userpassword from FTP_USER WHERE
> userid='{userid}' AND userpassword='{userpassword}'
> 2- Modify DbUserManager.authenticate from:
> HashMap map = new HashMap();
> map.put(ATTR_LOGIN, escapeString(user));
> To this one:
> HashMap map = new HashMap();
> map.put(ATTR_LOGIN, escapeString(user));
> map.put(ATTR_PASSWORD,
> getPasswordEncryptor().encrypt(password));
> Notice bug https://issues.apache.org/jira/browse/FTPSERVER-105 is unfixed in
> 1.0.0-RC1 and need to add command "INSERT IGNORE" or MySQL won't run.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-260) IOException under high load
[ https://issues.apache.org/jira/browse/FTPSERVER-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12665178#action_12665178 ] David Latorre commented on FTPSERVER-260: - After checking jakarta-jmeter source code it showed up that JMeter tests failing were due to their misuse of commons-net ftp. Commons javadoc for retrieveFileStream states: To finalize the file transfer you must call completePendingCommand and check its return value to verify success. In case you don't call completePendingCommand any subsequent attempt to retrieve a file will fail - this is why those errors appeared on FTPServer. Please note that the 'equivalent' retrieveFile doesn't need a call to completePendingCommand afterwards. John can you check you are not having the same problem (or a equivalent one) ? > IOException under high load > --- > > Key: FTPSERVER-260 > URL: https://issues.apache.org/jira/browse/FTPSERVER-260 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0.0-M3, 1.0.0-M4 > Environment: Windows XP SP3 >Reporter: John Hearn > Attachments: FTP_LOAD_TEST.jmx > > > Under high load I noticed that strange IOExceptions started appearing in the > server log: > java.io.IOException: Se ha anulado una conexión establecida por el software > en su equipo host. > at sun.nio.ch.SocketDispatcher.read0(Native Method) > at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:25) > at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:233) > at sun.nio.ch.IOUtil.read(IOUtil.java:206) > at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:207) > at > org.apache.mina.transport.socket.nio.NioProcessor.read(NioProcessor.java:175) > at > org.apache.mina.transport.socket.nio.NioProcessor.read(NioProcessor.java:42) > at > org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:561) > at > org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:540) > at > org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:532) > at > org.apache.mina.core.polling.AbstractPollingIoProcessor.access$400(AbstractPollingIoProcessor.java:58) > at > org.apache.mina.core.polling.AbstractPollingIoProcessor$Worker.run(AbstractPollingIoProcessor.java:857) > at > org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) > at java.lang.Thread.run(Thread.java:595) > (The message is in spanish because I am in Spain. I believe the exception in > english is "Software caused connection abort" but I may be wrong). > I couldn't find a related bug so as a test I set up a JMeter test rig with a > Thread Group and a basic (passive) FTP Request (user admin, RETR README.txt). > Sure enough when I increase the concurrent threads this error starts > appearing. In fact the error can appear occacionally with a single thread > downloading many files consecutively. > I have tried this with the latest versions of both JMeter and FtpServer and > the error is the same. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-262) FileSystemView.dispose() is never called
[ https://issues.apache.org/jira/browse/FTPSERVER-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12663305#action_12663305 ] David Latorre commented on FTPSERVER-262: - We should take into account that (I guess!) it is possible that the session be closed before the DataConnection ( so we can have a thread still writing to the filesystem). > FileSystemView.dispose() is never called > > > Key: FTPSERVER-262 > URL: https://issues.apache.org/jira/browse/FTPSERVER-262 > Project: FtpServer > Issue Type: Bug > Components: Ftplets >Affects Versions: 1.0.0-M4 >Reporter: Daniel Santos > > The FileSystemView.dispose() function is never called. > This method seems interesting to release critical resources such as JDBC > connections, email sessions, etc. > I think it is a good idea to call it when FtpSession closes (on > DefaultFtpHandler.sessionClosed()) and maybe when user login again (because > FileSystemView is related to an user). > thx -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-260) IOException under high load
[ https://issues.apache.org/jira/browse/FTPSERVER-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12662036#action_12662036 ] David Latorre commented on FTPSERVER-260: - Hello John, Can you provide a test case for this? (JMETER's .jmx files?) The original message for the exception is: java.io.IOException: An established connection was aborted by the software in your host machine - googling around I would say this Error message is thrown from the native layer (windows) -or at least .NET uses the very same message :-) Have you checked your firewall/antivirus configuration? It could also be some issue with MINA's implementation or NIO itself ... > IOException under high load > --- > > Key: FTPSERVER-260 > URL: https://issues.apache.org/jira/browse/FTPSERVER-260 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0.0-M3, 1.0.0-M4 > Environment: Windows XP SP3 >Reporter: John Hearn > > Under high load I noticed that strange IOExceptions started appearing in the > server log: > java.io.IOException: Se ha anulado una conexión establecida por el software > en su equipo host. > at sun.nio.ch.SocketDispatcher.read0(Native Method) > at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:25) > at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:233) > at sun.nio.ch.IOUtil.read(IOUtil.java:206) > at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:207) > at > org.apache.mina.transport.socket.nio.NioProcessor.read(NioProcessor.java:175) > at > org.apache.mina.transport.socket.nio.NioProcessor.read(NioProcessor.java:42) > at > org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:561) > at > org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:540) > at > org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:532) > at > org.apache.mina.core.polling.AbstractPollingIoProcessor.access$400(AbstractPollingIoProcessor.java:58) > at > org.apache.mina.core.polling.AbstractPollingIoProcessor$Worker.run(AbstractPollingIoProcessor.java:857) > at > org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) > at java.lang.Thread.run(Thread.java:595) > (The message is in spanish because I am in Spain. I believe the exception in > english is "Software caused connection abort" but I may be wrong). > I couldn't find a related bug so as a test I set up a JMeter test rig with a > Thread Group and a basic (passive) FTP Request (user admin, RETR README.txt). > Sure enough when I increase the concurrent threads this error starts > appearing. In fact the error can appear occacionally with a single thread > downloading many files consecutively. > I have tried this with the latest versions of both JMeter and FtpServer and > the error is the same. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (FTPSERVER-251) IoUtils.close() operation takes a long time when using implicit SSL
[
https://issues.apache.org/jira/browse/FTPSERVER-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Latorre reassigned FTPSERVER-251:
---
Assignee: David Latorre
> IoUtils.close() operation takes a long time when using implicit SSL
> ---
>
> Key: FTPSERVER-251
> URL: https://issues.apache.org/jira/browse/FTPSERVER-251
> Project: FtpServer
> Issue Type: Bug
> Components: Server
>Affects Versions: 1.0.0-RC1
> Environment: SLES 10 Java6 1.0.0-M4 (with SSL patch for FTPSERVER-241)
>Reporter: Randy Prager
>Assignee: David Latorre
> Fix For: 1.0.0-RC1
>
>
> Using a configuration for implicit SSL. & PASV connections
> Client is Auth TLS + PASV
>
> name="default"
> port="XXX"
> implicit-ssl="false"
> idle-timeout="60"
> local-address="XXX">
>
>
>
>
>
> external-address=""/>
>
>
>
>
>
> The LIST command takes approx 10 seconds to complete.
> It appears that the call to IoUtils.close() in method
> IODataConnection.transferToClient() is the culprit.
> I put some trace in the finally block:
>if (writer != null) {
> start = System.currentTimeMillis();
> writer.flush();
> LOG.info("flush in ["+(System.currentTimeMillis()-start)+"]
> ms.");
>}
> start = System.currentTimeMillis();
> IoUtils.close(writer);
> LOG.info("close in ["+(System.currentTimeMillis()-start)+"] ms.");
> [ INFO] 2008-12-23 12:22:13,892 flush in [0] ms.
> [ INFO] 2008-12-23 12:22:24,086 close in [10193] ms.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-251) IoUtils.close() operation takes a long time when using implicit SSL
[
https://issues.apache.org/jira/browse/FTPSERVER-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12660108#action_12660108
]
David Latorre commented on FTPSERVER-251:
-
Hello ,
Randy I've been trying to reproduce this bug using SSL/TLS implicit mode with
a PASV connection but I wasn't successful.
For this I used the SSL test cases in FtpServer and also Sai's excellent jFTP
and both worked fine.
Have you checked this bug with any other clients?
Maybe you can provide a test case or at least the actual configuration that is
causing your issue.
> IoUtils.close() operation takes a long time when using implicit SSL
> ---
>
> Key: FTPSERVER-251
> URL: https://issues.apache.org/jira/browse/FTPSERVER-251
> Project: FtpServer
> Issue Type: Bug
> Components: Server
>Affects Versions: 1.0.0-RC1
> Environment: SLES 10 Java6 1.0.0-M4 (with SSL patch for FTPSERVER-241)
>Reporter: Randy Prager
> Fix For: 1.0.0-RC1
>
>
> Using a configuration for implicit SSL. & PASV connections
> Client is Auth TLS + PASV
>
> name="default"
> port="XXX"
> implicit-ssl="false"
> idle-timeout="60"
> local-address="XXX">
>
>
>
>
>
> external-address=""/>
>
>
>
>
>
> The LIST command takes approx 10 seconds to complete.
> It appears that the call to IoUtils.close() in method
> IODataConnection.transferToClient() is the culprit.
> I put some trace in the finally block:
>if (writer != null) {
> start = System.currentTimeMillis();
> writer.flush();
> LOG.info("flush in ["+(System.currentTimeMillis()-start)+"]
> ms.");
>}
> start = System.currentTimeMillis();
> IoUtils.close(writer);
> LOG.info("close in ["+(System.currentTimeMillis()-start)+"] ms.");
> [ INFO] 2008-12-23 12:22:13,892 flush in [0] ms.
> [ INFO] 2008-12-23 12:22:24,086 close in [10193] ms.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FTPSERVER-249) DBUserManager doesn't close Connections leading to pool exhaustion.
[ https://issues.apache.org/jira/browse/FTPSERVER-249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre resolved FTPSERVER-249. - Resolution: Fixed Sorry I've been away for some days. Since we are opening a new connection for each call this fix should do it. > DBUserManager doesn't close Connections leading to pool exhaustion. > --- > > Key: FTPSERVER-249 > URL: https://issues.apache.org/jira/browse/FTPSERVER-249 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0.0-M4 >Reporter: David Latorre >Assignee: David Latorre > Fix For: 1.0.0-RC1 > > > DBUserManager creates a new Connection in every call but never returns the > connections to the pool. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-249) DBUserManager doesn't close Connections leading to pool exhaustion.
DBUserManager doesn't close Connections leading to pool exhaustion. --- Key: FTPSERVER-249 URL: https://issues.apache.org/jira/browse/FTPSERVER-249 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0.0-M4 Reporter: David Latorre Assignee: David Latorre Fix For: 1.0.0-RC1 DBUserManager creates a new Connection in every call but never returns the connections to the pool. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FTPSERVER-227) RMD command should not delete the current working directory or the any parent of current working directory
[ https://issues.apache.org/jira/browse/FTPSERVER-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre resolved FTPSERVER-227. - Resolution: Fixed Do you agree with this fix? Or should we trasverse the parentFile()s in order to know if we are trying to delete an 'ancestor' of our current working directory? > RMD command should not delete the current working directory or the any parent > of current working directory > -- > > Key: FTPSERVER-227 > URL: https://issues.apache.org/jira/browse/FTPSERVER-227 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0.0-M4 >Reporter: Sai Pullabhotla >Assignee: David Latorre > Fix For: 1.0.0-RC1 > > Attachments: FTPSERVER-227_patch.text > > > RMD command should not delete the current working directory or the any parent > of current working directory. > case 1: Let us say, the current working directory is "/wd" then "RMD ." or > RMD "/wd" should result in a 5XX reply. > case 2: Let us say the working directory is "/wd/subdir", then RMD /wd or > "RMD .." should also be restricted and a 5xx reply should be sent. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-227) RMD command should not delete the current working directory or the any parent of current working directory
[ https://issues.apache.org/jira/browse/FTPSERVER-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655231#action_12655231 ] David Latorre commented on FTPSERVER-227: - Should be fixed at revision 725059. I changed the error code to 450 which indeed seems more appropriate so I had to update the test case "for case-insensitive" systems. Other than it is Sai's patch I think. Thanks Sai! Probably we should also check if we are deleting a parent directory from the cwd but we could keep adding patches and nothing but file locking would solve all the possible issues. > RMD command should not delete the current working directory or the any parent > of current working directory > -- > > Key: FTPSERVER-227 > URL: https://issues.apache.org/jira/browse/FTPSERVER-227 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0.0-M4 >Reporter: Sai Pullabhotla >Assignee: David Latorre > Fix For: 1.0.0-RC1 > > Attachments: FTPSERVER-227_patch.text > > > RMD command should not delete the current working directory or the any parent > of current working directory. > case 1: Let us say, the current working directory is "/wd" then "RMD ." or > RMD "/wd" should result in a 5XX reply. > case 2: Let us say the working directory is "/wd/subdir", then RMD /wd or > "RMD .." should also be restricted and a 5xx reply should be sent. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (FTPSERVER-227) RMD command should not delete the current working directory or the any parent of current working directory
[ https://issues.apache.org/jira/browse/FTPSERVER-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre reassigned FTPSERVER-227: --- Assignee: David Latorre > RMD command should not delete the current working directory or the any parent > of current working directory > -- > > Key: FTPSERVER-227 > URL: https://issues.apache.org/jira/browse/FTPSERVER-227 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0.0-M4 >Reporter: Sai Pullabhotla >Assignee: David Latorre > Fix For: 1.0.0-RC1 > > Attachments: FTPSERVER-227_patch.text > > > RMD command should not delete the current working directory or the any parent > of current working directory. > case 1: Let us say, the current working directory is "/wd" then "RMD ." or > RMD "/wd" should result in a 5XX reply. > case 2: Let us say the working directory is "/wd/subdir", then RMD /wd or > "RMD .." should also be restricted and a 5xx reply should be sent. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (FTPSERVER-229) MFMT Command - Code Enhancement
[ https://issues.apache.org/jira/browse/FTPSERVER-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre reopened FTPSERVER-229: - We should see if we want to fix this , accessing DateFormat in a thread-safe way. Sorry for 'resolving' issues too soon (and not committing them!). > MFMT Command - Code Enhancement > --- > > Key: FTPSERVER-229 > URL: https://issues.apache.org/jira/browse/FTPSERVER-229 > Project: FtpServer > Issue Type: Improvement > Components: Core >Affects Versions: 1.0.0-M4 >Reporter: Sai Pullabhotla >Assignee: David Latorre > Fix For: 1.0.0-RC1 > > > MFMT Command - in the source code for this command (MFMT.java), the > DateFormat and > its configuration should be moved to static block for performance and to > reduce object creations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-226) DELE command deletes directories
[ https://issues.apache.org/jira/browse/FTPSERVER-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre updated FTPSERVER-226: Fix Version/s: (was: 1.0.0-M4) 1.0.0-RC1 > DELE command deletes directories > > > Key: FTPSERVER-226 > URL: https://issues.apache.org/jira/browse/FTPSERVER-226 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0.0-M3 >Reporter: Sai Pullabhotla > Fix For: 1.0.0-RC1 > > > DELE command should NOT delete the object if the argument represents a > directory. According to the FTP Standards RMD command should be used for > deleting directories. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-228) LIST command on a non-existent directory should result in an error
[ https://issues.apache.org/jira/browse/FTPSERVER-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre updated FTPSERVER-228: Fix Version/s: (was: 1.0.0-M4) 1.0.0-RC1 > LIST command on a non-existent directory should result in an error > -- > > Key: FTPSERVER-228 > URL: https://issues.apache.org/jira/browse/FTPSERVER-228 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0.0-M3 >Reporter: Sai Pullabhotla > Fix For: 1.0.0-RC1 > > > LIST command on a non-existent directory should result in an error. Instead, > we send an empty list back. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FTPSERVER-227) DELE command should not delete the current working directory or the any parent of current working directory
[ https://issues.apache.org/jira/browse/FTPSERVER-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre closed FTPSERVER-227. --- Resolution: Duplicate According to FTPSERVER-226 DELE shouldn't delete any directories so this issue is already addressed. > DELE command should not delete the current working directory or the any > parent of current working directory > --- > > Key: FTPSERVER-227 > URL: https://issues.apache.org/jira/browse/FTPSERVER-227 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0.0-M3 >Reporter: Sai Pullabhotla > Fix For: 1.0.0-M4 > > > DELE command should not delete the current working directory or the any > parent of current working directory. > case 1: Let us say, the current working directory is "/wd" then "DELE ." or > DELE "/wd" should result in a 5XX reply. > case 2: Let us say the working directory is "/wd/subdir", then DELE /wd or > "DELE .." should also be restricted and a 5xx reply should be sent. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FTPSERVER-234) TYPE command with no argument
[ https://issues.apache.org/jira/browse/FTPSERVER-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre resolved FTPSERVER-234. - Resolution: Fixed Fix Version/s: (was: 1.0.0-M4) 1.0.0-RC1 Makes sense.RFC doesn't list the first parameter as optional. Fix will be provided for 1.0.0-RC1. > TYPE command with no argument > - > > Key: FTPSERVER-234 > URL: https://issues.apache.org/jira/browse/FTPSERVER-234 > Project: FtpServer > Issue Type: Improvement > Components: Core >Affects Versions: 1.0.0-M3 >Reporter: Sai Pullabhotla > Fix For: 1.0.0-RC1 > > > Not sure if TYPE command with no argument should change the type to ASCII. > Instead it should reply back with 2xx reply indicating the current type in > use. Not sure what the RFC says. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FTPSERVER-232) MFMT command always returns a 2XX reply even if the date could not be set
[ https://issues.apache.org/jira/browse/FTPSERVER-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre resolved FTPSERVER-232. - Resolution: Fixed Fix Version/s: (was: 1.0.0-M4) 1.0.0-RC1 Assignee: David Latorre Fix will be provided for 1.0.0-RC1. > MFMT command always returns a 2XX reply even if the date could not be set > - > > Key: FTPSERVER-232 > URL: https://issues.apache.org/jira/browse/FTPSERVER-232 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0.0-M3 >Reporter: Sai Pullabhotla >Assignee: David Latorre > Fix For: 1.0.0-RC1 > > > MFMT command always returns a 2XX reply even if the date could not be set. > MFMT Command should return a Positive Completion Reply if and only if we are > sure that the date on the file was modified. In order to fix this, we need to > make use of the return value from java.io.File.setLastModified(long). We are > not using the returned boolean from this method and assuming that the new > date was set. Code needs to be changed in a few places to fix this. The issue > can be reproduced by trying to set the date on a file that is in use. I used > a .doc file, had it open in MS Word and ran the MFMT command and got the 213 > reply, but the date on the file was not changed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FTPSERVER-231) MFMT Commad does not work on file/path names that have one or more white spaces
[
https://issues.apache.org/jira/browse/FTPSERVER-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Latorre resolved FTPSERVER-231.
-
Resolution: Fixed
Fix Version/s: (was: 1.0.0-M4)
1.0.0-RC1
Assignee: David Latorre
Fix will be provided for 1.0.0-RC1.
> MFMT Commad does not work on file/path names that have one or more white
> spaces
> ---
>
> Key: FTPSERVER-231
> URL: https://issues.apache.org/jira/browse/FTPSERVER-231
> Project: FtpServer
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.0.0-M3
>Reporter: Sai Pullabhotla
>Assignee: David Latorre
> Fix For: 1.0.0-RC1
>
>
> MFMT Commad does not work on file/path names that have one or more white
> spaces.
> For example if you have a file named "my file.txt", running the MFMT command
> on this file fails.
> To fix this, the MFMT.java needs to be changes as follows:
> String[] arguments = argument.split(" "); should be changed to
> String[] arguments = arguments.split(" ", 2);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FTPSERVER-230) MFMT Command reply should include a message
[ https://issues.apache.org/jira/browse/FTPSERVER-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre resolved FTPSERVER-230. - Resolution: Fixed Fix Version/s: (was: 1.0.0-M4) 1.0.0-RC1 Fix will be provided for 1.0.0-RC1. > MFMT Command reply should include a message > --- > > Key: FTPSERVER-230 > URL: https://issues.apache.org/jira/browse/FTPSERVER-230 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0.0-M3 >Reporter: Sai Pullabhotla >Assignee: David Latorre > Fix For: 1.0.0-RC1 > > > MFMT Command replies with just the code 213. We might want to add a message > at least saying requested action was successful. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FTPSERVER-229) MFMT Command - Code Enhancement
[ https://issues.apache.org/jira/browse/FTPSERVER-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre resolved FTPSERVER-229. - Resolution: Fixed Fix Version/s: (was: 1.0.0-M4) 1.0.0-RC1 Fix will be provided for 1.0.0-RC1. > MFMT Command - Code Enhancement > --- > > Key: FTPSERVER-229 > URL: https://issues.apache.org/jira/browse/FTPSERVER-229 > Project: FtpServer > Issue Type: Improvement > Components: Core >Affects Versions: 1.0.0-M3 >Reporter: Sai Pullabhotla >Assignee: David Latorre > Fix For: 1.0.0-RC1 > > > MFMT Command - in the source code for this command (MFMT.java), the > DateFormat and > its configuration should be moved to static block for performance and to > reduce object creations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (FTPSERVER-229) MFMT Command - Code Enhancement
[ https://issues.apache.org/jira/browse/FTPSERVER-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre reassigned FTPSERVER-229: --- Assignee: David Latorre > MFMT Command - Code Enhancement > --- > > Key: FTPSERVER-229 > URL: https://issues.apache.org/jira/browse/FTPSERVER-229 > Project: FtpServer > Issue Type: Improvement > Components: Core >Affects Versions: 1.0.0-M3 >Reporter: Sai Pullabhotla >Assignee: David Latorre > Fix For: 1.0.0-M4 > > > MFMT Command - in the source code for this command (MFMT.java), the > DateFormat and > its configuration should be moved to static block for performance and to > reduce object creations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (FTPSERVER-230) MFMT Command reply should include a message
[ https://issues.apache.org/jira/browse/FTPSERVER-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre reassigned FTPSERVER-230: --- Assignee: David Latorre > MFMT Command reply should include a message > --- > > Key: FTPSERVER-230 > URL: https://issues.apache.org/jira/browse/FTPSERVER-230 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0.0-M3 >Reporter: Sai Pullabhotla >Assignee: David Latorre > Fix For: 1.0.0-M4 > > > MFMT Command replies with just the code 213. We might want to add a message > at least saying requested action was successful. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-230) MFMT Command reply should include a message
[ https://issues.apache.org/jira/browse/FTPSERVER-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12653054#action_12653054 ] David Latorre commented on FTPSERVER-230: - Although there is no official RFC including MFTM , there's a draft so we might want to follow it for this issue: http://tools.ietf.org/html/draft-somers-ftp-mfxx-04#section-3.1 So the correct response when the command succeded is: mfmt-response = "213" SP "Modify=" time-val ";" SP pathname CRLF > MFMT Command reply should include a message > --- > > Key: FTPSERVER-230 > URL: https://issues.apache.org/jira/browse/FTPSERVER-230 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0.0-M3 >Reporter: Sai Pullabhotla > Fix For: 1.0.0-M4 > > > MFMT Command replies with just the code 213. We might want to add a message > at least saying requested action was successful. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FTPSERVER-136) incorrent IP used in opening data channel
[ https://issues.apache.org/jira/browse/FTPSERVER-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre closed FTPSERVER-136. --- Amichai can you test this? I have to find an automatic and portable way to test this. You can change your ip address (e.g, with ifconfig in Unix) and test if connection still works . But since ipaliasing in my linux box doesn't work and actually changes the ip address rather than adding a new one I cannot automate tests. > incorrent IP used in opening data channel > - > > Key: FTPSERVER-136 > URL: https://issues.apache.org/jira/browse/FTPSERVER-136 > Project: FtpServer > Issue Type: Bug > Environment: Windows XP >Reporter: Amichai Rothman >Assignee: David Latorre >Priority: Minor > Fix For: 1.0-M4 > > > The IP used in opening the data channel (DATA command) appears to be > determined when the ftp server starts, and never updated again. On systems > where the IP address might change (such as any dynamic dns host) this causes > all data connections to fail, and requires a full restart of the service > whenever the IP address changes (which makes the availability of the ftp > server unreliable for practical use). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FTPSERVER-136) incorrent IP used in opening data channel
[ https://issues.apache.org/jira/browse/FTPSERVER-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre resolved FTPSERVER-136. - Resolution: Fixed > incorrent IP used in opening data channel > - > > Key: FTPSERVER-136 > URL: https://issues.apache.org/jira/browse/FTPSERVER-136 > Project: FtpServer > Issue Type: Bug > Environment: Windows XP >Reporter: Amichai Rothman >Assignee: David Latorre >Priority: Minor > Fix For: 1.0-M4 > > > The IP used in opening the data channel (DATA command) appears to be > determined when the ftp server starts, and never updated again. On systems > where the IP address might change (such as any dynamic dns host) this causes > all data connections to fail, and requires a full restart of the service > whenever the IP address changes (which makes the availability of the ftp > server unreliable for practical use). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-136) incorrent IP used in opening data channel
[ https://issues.apache.org/jira/browse/FTPSERVER-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648680#action_12648680 ] David Latorre commented on FTPSERVER-136: - Patch applied in 718667. The solution should work but there are a lot of nasty hacks in the code. We should want to unify all the different methods which transform a String into an InetAddress ( we should throw a single Exception then). > incorrent IP used in opening data channel > - > > Key: FTPSERVER-136 > URL: https://issues.apache.org/jira/browse/FTPSERVER-136 > Project: FtpServer > Issue Type: Bug > Environment: Windows XP >Reporter: Amichai Rothman >Assignee: David Latorre >Priority: Minor > Fix For: 1.0-M4 > > > The IP used in opening the data channel (DATA command) appears to be > determined when the ftp server starts, and never updated again. On systems > where the IP address might change (such as any dynamic dns host) this causes > all data connections to fail, and requires a full restart of the service > whenever the IP address changes (which makes the availability of the ftp > server unreliable for practical use). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (FTPSERVER-136) incorrent IP used in opening data channel
[ https://issues.apache.org/jira/browse/FTPSERVER-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre reassigned FTPSERVER-136: --- Assignee: David Latorre (was: Niklas Gustavsson) > incorrent IP used in opening data channel > - > > Key: FTPSERVER-136 > URL: https://issues.apache.org/jira/browse/FTPSERVER-136 > Project: FtpServer > Issue Type: Bug > Environment: Windows XP >Reporter: Amichai Rothman >Assignee: David Latorre >Priority: Minor > Fix For: 1.0-M4 > > > The IP used in opening the data channel (DATA command) appears to be > determined when the ftp server starts, and never updated again. On systems > where the IP address might change (such as any dynamic dns host) this causes > all data connections to fail, and requires a full restart of the service > whenever the IP address changes (which makes the availability of the ftp > server unreliable for practical use). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-219) The STOR command hangs thread in passive mode
[ https://issues.apache.org/jira/browse/FTPSERVER-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648176#action_12648176 ] David Latorre commented on FTPSERVER-219: - Fixed in #714088. I think you can close this niklas. I was checking if my write permission to the repo was ok; but I forgot about jira permissions. > The STOR command hangs thread in passive mode > - > > Key: FTPSERVER-219 > URL: https://issues.apache.org/jira/browse/FTPSERVER-219 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0-M3, 1.0-M4 > Environment: Debian Linux > Jdk 1.6.0_10 >Reporter: Mikael Svahn > > If a client does not disconnect a STOR command correct, for instance due to > bad transmission the reader thread might hang. I think there must be a > timeout on socket read. > - java.net.SocketInputStream.socketRead0(java.io.FileDescriptor, byte[], > int, int, int) @bci=0 (Interpreted frame) > - java.net.SocketInputStream.read(byte[], int, int) @bci=84, line=129 > (Interpreted frame) > - java.io.BufferedInputStream.fill() @bci=175, line=218 (Compiled frame) > - java.io.BufferedInputStream.read1(byte[], int, int) @bci=44, line=258 > (Compiled frame) > - java.io.BufferedInputStream.read(byte[], int, int) @bci=49, line=317 > (Interpreted frame) > - java.io.FilterInputStream.read(byte[]) @bci=5, line=90 (Interpreted frame) > - > org.apache.ftpserver.impl.IODataConnection.transfer(org.apache.ftpserver.ftplet.FtpSession, > boolean, java.io.InputStream, java.io.OutputStream, int) @bci=133, line=236 > (Interpreted frame) > - > org.apache.ftpserver.impl.IODataConnection.transferFromClient(org.apache.ftpserver.ftplet.FtpSession, > java.io.OutputStream) @bci=51, line=129 (Interpreted frame) > - > org.apache.ftpserver.command.impl.STOR.execute(org.apache.ftpserver.impl.FtpIoSession, > org.apache.ftpserver.impl.FtpServerContext, > org.apache.ftpserver.ftplet.FtpRequest) @bci=344, line=147 (Interpreted frame) > - > org.apache.ftpserver.impl.DefaultFtpHandler.messageReceived(org.apache.ftpserver.impl.FtpIoSession, > org.apache.ftpserver.ftplet.FtpRequest) @bci=160, line=135 (Interpreted > frame) > - > org.apache.ftpserver.listener.nio.FtpHandlerAdapter.messageReceived(org.apache.mina.core.session.IoSession, > java.lang.Object) @bci=33, line=62 (Interpreted frame) > - > org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(org.apache.mina.core.filterchain.IoFilter$NextFilter, > org.apache.mina.core.session.IoSession, java.lang.Object) @bci=51, line=752 > (Inte -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-219) The STOR command hangs thread in passive mode
[ https://issues.apache.org/jira/browse/FTPSERVER-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12646531#action_12646531 ] David Latorre commented on FTPSERVER-219: - I don't have the code here but it should be easy - just use setSoTimeout , right ? a patch will be welcome if you have already fixed this! > The STOR command hangs thread in passive mode > - > > Key: FTPSERVER-219 > URL: https://issues.apache.org/jira/browse/FTPSERVER-219 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0-M3, 1.0-M4 > Environment: Debian Linux > Jdk 1.6.0_10 >Reporter: Mikael Svahn > > If a client does not disconnect a STOR command correct, for instance due to > bad transmission the reader thread might hang. I think there must be a > timeout on socket read. > - java.net.SocketInputStream.socketRead0(java.io.FileDescriptor, byte[], > int, int, int) @bci=0 (Interpreted frame) > - java.net.SocketInputStream.read(byte[], int, int) @bci=84, line=129 > (Interpreted frame) > - java.io.BufferedInputStream.fill() @bci=175, line=218 (Compiled frame) > - java.io.BufferedInputStream.read1(byte[], int, int) @bci=44, line=258 > (Compiled frame) > - java.io.BufferedInputStream.read(byte[], int, int) @bci=49, line=317 > (Interpreted frame) > - java.io.FilterInputStream.read(byte[]) @bci=5, line=90 (Interpreted frame) > - > org.apache.ftpserver.impl.IODataConnection.transfer(org.apache.ftpserver.ftplet.FtpSession, > boolean, java.io.InputStream, java.io.OutputStream, int) @bci=133, line=236 > (Interpreted frame) > - > org.apache.ftpserver.impl.IODataConnection.transferFromClient(org.apache.ftpserver.ftplet.FtpSession, > java.io.OutputStream) @bci=51, line=129 (Interpreted frame) > - > org.apache.ftpserver.command.impl.STOR.execute(org.apache.ftpserver.impl.FtpIoSession, > org.apache.ftpserver.impl.FtpServerContext, > org.apache.ftpserver.ftplet.FtpRequest) @bci=344, line=147 (Interpreted frame) > - > org.apache.ftpserver.impl.DefaultFtpHandler.messageReceived(org.apache.ftpserver.impl.FtpIoSession, > org.apache.ftpserver.ftplet.FtpRequest) @bci=160, line=135 (Interpreted > frame) > - > org.apache.ftpserver.listener.nio.FtpHandlerAdapter.messageReceived(org.apache.mina.core.session.IoSession, > java.lang.Object) @bci=33, line=62 (Interpreted frame) > - > org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(org.apache.mina.core.filterchain.IoFilter$NextFilter, > org.apache.mina.core.session.IoSession, java.lang.Object) @bci=51, line=752 > (Inte -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FTPSERVER-215) Secured data channel in active mode would require the server to have a public certificate for every client.
[ https://issues.apache.org/jira/browse/FTPSERVER-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre closed FTPSERVER-215. --- Resolution: Invalid Having the server call setUseClientMode() as it already does should be enough. > Secured data channel in active mode would require the server to have a public > certificate for every client. > --- > > Key: FTPSERVER-215 > URL: https://issues.apache.org/jira/browse/FTPSERVER-215 > Project: FtpServer > Issue Type: Improvement > Components: Core >Affects Versions: 1.0-M1, 1.0-M2, 1.0-M3, 1.0-M4 >Reporter: David Latorre > Fix For: 1.0-M4 > > > In "active mode" , the FtpServer itself will try to open a connection to a > client-reported host and port. > In this case, if we were using a SSL connection, the server opens a > connection to the client so it will receive the client's public certificate > and will try and check it against its TrustStore. > To my mind, when we are not checking the client certificate we shouldn't > check it in Active data connections either. So we should provide our own > TrustManager for this. > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-215) Secured data channel in active mode would require the server to have a public certificate for every client.
[ https://issues.apache.org/jira/browse/FTPSERVER-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12645732#action_12645732 ] David Latorre commented on FTPSERVER-215: - Secured data channel in active mode would require the server to have a public certificate for every client. >This is not true, it would be verified against the signer, which might very >well be a known CA certificate (like Verisign) Sure. But in most common scenarios, people don't buy a Versign certificate just to connect to a HTTPS/FTPS server. So that was the worst-case scenario. Anyway, never mind my post I realized that my problem was with a bug in commons net ftp I am going to report(provide a fix for) now. FTPServer correctly creates the socket with useClientMode=false. So, if clients do not use SSL client mode themselves, that should be their fault. Do you agree? So this issue can be closed. Sorry! > Secured data channel in active mode would require the server to have a public > certificate for every client. > --- > > Key: FTPSERVER-215 > URL: https://issues.apache.org/jira/browse/FTPSERVER-215 > Project: FtpServer > Issue Type: Improvement > Components: Core >Affects Versions: 1.0-M1, 1.0-M2, 1.0-M3, 1.0-M4 >Reporter: David Latorre > Fix For: 1.0-M4 > > > In "active mode" , the FtpServer itself will try to open a connection to a > client-reported host and port. > In this case, if we were using a SSL connection, the server opens a > connection to the client so it will receive the client's public certificate > and will try and check it against its TrustStore. > To my mind, when we are not checking the client certificate we shouldn't > check it in Active data connections either. So we should provide our own > TrustManager for this. > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-184) IODataConnection ASCII mode does not work as expected.
[
https://issues.apache.org/jira/browse/FTPSERVER-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12645656#action_12645656
]
David Latorre commented on FTPSERVER-184:
-
Hello,
Sure you are right here, I didn't make myself clear enough Im sorry.
As you (and RFC959) say, when we are sending the file we should transform to
NVT-ASCII but not when we are receiving the file. In this second case, i think
that the expected behaviour is that the text message be written to a file with
the default line separator for the platform.
The sender converts the data from an internal character
representation to the standard 8-bit NVT-ASCII
representation (see the Telnet specification). The receiver
will convert the data from the standard form to his own
internal form.
Actually , according to the spec before a RETR ASCII operation is transformed
we should be converting the charset to ASCII , for our machine could be using
EBCDIC to store files and clients are supposed to expect that files are
encoded in NVT-ASCII.
So I don't know ... Any way, this has little priority for me (until someone
using a non-ascii-compatible encoding complains) so we could leave this for the
future. Any way I don't like ASCII mode for it breaks the 'REST' command. My
implementation only supports binary mode.
> IODataConnection ASCII mode does not work as expected.
> --
>
> Key: FTPSERVER-184
> URL: https://issues.apache.org/jira/browse/FTPSERVER-184
> Project: FtpServer
> Issue Type: Improvement
> Components: Core
>Affects Versions: 1.0-M2, 1.0-M3
>Reporter: David Latorre
>Assignee: Niklas Gustavsson
> Fix For: 1.0-M4
>
>
> New lines in files sent in ASCII mode are transformed into /r/n no matter
> what platform the ftp server is running on. But if I'm not wrong, the new
> EOL should be equal to "line.separator" . If ASCII mode is going to be
> supported, this ought to be changed.
>
> The code in IODataConnection.transfer()
> {
> if (isAscii) {
> for (int i = 0; i < count; ++i) {
> byte b = buff[i];
> if (b == '\n' && !lastWasCR) {
> bos.write('\r');
> }
> if (b == '\r') {
> lastWasCR = true;
> } else {
> lastWasCR = false;
> }
> bos.write(b);
> }
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-215) Secured data channel in active mode would require the server to have a public certificate for every client.
Secured data channel in active mode would require the server to have a public certificate for every client. --- Key: FTPSERVER-215 URL: https://issues.apache.org/jira/browse/FTPSERVER-215 Project: FtpServer Issue Type: Improvement Components: Core Affects Versions: 1.0-M3, 1.0-M2, 1.0-M1, 1.0-M4 Reporter: David Latorre Fix For: 1.0-M4 In "active mode" , the FtpServer itself will try to open a connection to a client-reported host and port. In this case, if we were using a SSL connection, the server opens a connection to the client so it will receive the client's public certificate and will try and check it against its TrustStore. To my mind, when we are not checking the client certificate we shouldn't check it in Active data connections either. So we should provide our own TrustManager for this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-136) incorrent IP used in opening data channel
[ https://issues.apache.org/jira/browse/FTPSERVER-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12640897#action_12640897 ] David Latorre commented on FTPSERVER-136: - Actually this behaviour I mentioned was changed in Java SE 6 (when there is no Security Manager) but my explanation to the problem was incorrect (although the problem I pointed out would also affect if we fixed this). Now, this is correct (I think) We are building the InetAddress object representing the External Ip Address (when explicitly stated) inside the ListenerBeanDefinitionParser so, as Amichal said, the IP address is never looked up again (InetAddress will lookup the hostname if we didn't provide one when we created the object but won't even know that we didn't provide a numeric ip address so it won't look it up again). The easiest solution I can see is to store the address information in a String fiend and have a getter which will return an InetAddress or retrieve it as a String and build the object when appropriate (Not a problem since we also need to retrieve the local ip if we didn't configure the field in the xml). > incorrent IP used in opening data channel > - > > Key: FTPSERVER-136 > URL: https://issues.apache.org/jira/browse/FTPSERVER-136 > Project: FtpServer > Issue Type: Bug > Environment: Windows XP >Reporter: Amichai Rothman >Assignee: Niklas Gustavsson >Priority: Minor > Fix For: 1.0-M4 > > > The IP used in opening the data channel (DATA command) appears to be > determined when the ftp server starts, and never updated again. On systems > where the IP address might change (such as any dynamic dns host) this causes > all data connections to fail, and requires a full restart of the service > whenever the IP address changes (which makes the availability of the ftp > server unreliable for practical use). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-136) incorrent IP used in opening data channel
[ https://issues.apache.org/jira/browse/FTPSERVER-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12640896#action_12640896 ] David Latorre commented on FTPSERVER-136: - So if I understand correctly, Amichal is providing a hostname (something like my-server.dyndns.org) as the external-ip-address in the passive data connection configuration. Is that right? Then, Amichal problem is that even if he's using a hostname which should be resolved through a DNS request, this name always point to the same address. This is because of the caching behaviour of InetAddress. From JavaDocs: InetAddress Caching The InetAddress class has a cache to store successful as well as unsuccessful host name resolutions. The positive caching is there to guard against DNS spoofing attacks; while the negative caching is used to improve performance. By default, the result of positive host name resolutions are cached forever, because there is no general rule to decide when it is safe to remove cache entries. Thus, we should set the security property which defines how long IP address will be cached: networkaddress.cache.ttl (default: -1) Indicates the caching policy for successful name lookups from the name service. The value is specified as as integer to indicate the number of seconds to cache the successful lookup. I find this could be a bit of a trouble because, most probably, Application Servers set themselves the property. And of course if a security manager is on we might not be able to change this setting. What do you think Niklas? Actually, that explanation about "spoofing prevention" is kinda laughable and I hope this cache forever default is dropped in the jdk! > incorrent IP used in opening data channel > - > > Key: FTPSERVER-136 > URL: https://issues.apache.org/jira/browse/FTPSERVER-136 > Project: FtpServer > Issue Type: Bug > Environment: Windows XP >Reporter: Amichai Rothman >Assignee: Niklas Gustavsson >Priority: Minor > Fix For: 1.0-M4 > > > The IP used in opening the data channel (DATA command) appears to be > determined when the ftp server starts, and never updated again. On systems > where the IP address might change (such as any dynamic dns host) this causes > all data connections to fail, and requires a full restart of the service > whenever the IP address changes (which makes the availability of the ftp > server unreliable for practical use). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-197) start() and stop() methods in FtpServer class can fail to unbind ports.
[ https://issues.apache.org/jira/browse/FTPSERVER-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre updated FTPSERVER-197: Affects Version/s: 1.0-M1 1.0-M2 1.0-M3 > start() and stop() methods in FtpServer class can fail to unbind ports. > > > Key: FTPSERVER-197 > URL: https://issues.apache.org/jira/browse/FTPSERVER-197 > Project: FtpServer > Issue Type: Bug >Affects Versions: 1.0-M1, 1.0-M2, 1.0-M3 >Reporter: David Latorre > > *start() method in FtpServer class tries to start() all the listeners one by > one and it sets started=true if all of them succeeded. > If one of the listeners throws an exception when starting but some others > succeded , it will not close the open listeners. Calling stop() won't have > any effect in this case as 'started' is false. > *stop() method in FtpServer class returns normally when e.g., there are > open connections to the FtpServer but the server is not really stopped. > Calling stop() again later won't have any effect as 'started' is false. > I'm quite concerned about the fact that calling stop() won't stop the server > since this means that when I undeploy my webapplication the port is still > open and I need to restart the whole application server in order to have this > port available (and prevent memory leaks!, I guess). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-197) start() and stop() methods in FtpServer class can fail to unbind ports.
start() and stop() methods in FtpServer class can fail to unbind ports. Key: FTPSERVER-197 URL: https://issues.apache.org/jira/browse/FTPSERVER-197 Project: FtpServer Issue Type: Bug Reporter: David Latorre *start() method in FtpServer class tries to start() all the listeners one by one and it sets started=true if all of them succeeded. If one of the listeners throws an exception when starting but some others succeded , it will not close the open listeners. Calling stop() won't have any effect in this case as 'started' is false. *stop() method in FtpServer class returns normally when e.g., there are open connections to the FtpServer but the server is not really stopped. Calling stop() again later won't have any effect as 'started' is false. I'm quite concerned about the fact that calling stop() won't stop the server since this means that when I undeploy my webapplication the port is still open and I need to restart the whole application server in order to have this port available (and prevent memory leaks!, I guess). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-196) Add an example of FTPserver deployed to an application server.
[ https://issues.apache.org/jira/browse/FTPSERVER-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre updated FTPSERVER-196: Attachment: ftpserver_in_a_War_Application.zip Netbeans sample project on how to deploy FtpServer to an application server. It is easy enough to create an Eclipse project with these files (you just copy the contents of 'src/java' directory into Eclipse's source root and web.xml to WEB-INF/web.xml. Although I tested it with Glassfish, it should work on most application servers or Servlet containers. Actually, it seems that a bug on Glassfish 2 (according to MINA guys) could prevent FtpServer from running on Windows machines. But it is working perfectly on our linux servers. src/java/ftpd-typical.xml should be edited to point to the appropiate keystore and user.properties files ( in resources/ users.properties there's an example of a user.properties files included in the source of Ftpserver core). > Add an example of FTPserver deployed to an application server. > -- > > Key: FTPSERVER-196 > URL: https://issues.apache.org/jira/browse/FTPSERVER-196 > Project: FtpServer > Issue Type: Improvement > Components: Server >Reporter: David Latorre > Attachments: ftpserver_in_a_War_Application.zip > > > An example should be added where FtpServer is deployed to an application > server. > Easiest way I can see: >- Deploy a web application containing Ftpserver Jars in WEB-INF/lib >- Configure a Listener in this application which will instantiate > FtpServer and call the start() or stop() methods as adequate. > An example is provided! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-196) Add an example of FTPserver deployed to an application server.
Add an example of FTPserver deployed to an application server. -- Key: FTPSERVER-196 URL: https://issues.apache.org/jira/browse/FTPSERVER-196 Project: FtpServer Issue Type: Improvement Components: Server Reporter: David Latorre An example should be added where FtpServer is deployed to an application server. Easiest way I can see: - Deploy a web application containing Ftpserver Jars in WEB-INF/lib - Configure a Listener in this application which will instantiate FtpServer and call the start() or stop() methods as adequate. An example is provided! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-185) Methods User#getAuthorities() is not used and should removed from the interface
[
https://issues.apache.org/jira/browse/FTPSERVER-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12635707#action_12635707
]
David Latorre commented on FTPSERVER-185:
-
sorry but I can't see what's your use-case here.
Can you comment on why you need your own User implementation (not extending
BaseUser!) and how you are implementing it so you can respond to
"AuthorizationRequests" but you don't have a list of Authorities you can return.
> Methods User#getAuthorities() is not used and should removed from the
> interface
> ---
>
> Key: FTPSERVER-185
> URL: https://issues.apache.org/jira/browse/FTPSERVER-185
> Project: FtpServer
> Issue Type: Bug
> Components: Ftplets
>Reporter: Andrea Francia
>
> As far I understand the User interface should specify how the User
> implementations should communicates with the ftpserver.
> The ftpserver doesn't known directly if a user is should be authorized to
> perform a specific action but it delegate this decisione to the User
> implementation.
> As I can see from the source code the method for determining if a user can
> perform a specific action is:
> public interface User {
>AuthorizationRequest authorize(AuthorizationRequest request);
> ...
> }
> So I don't see the purpose of put in the interface these methods:
> Authority[] getAuthorities();
> Authority[] getAuthorities(Class clazz);
> These methods are not used by the ftpserver so they should not go in the
> interface.
> The interface beetween two entities should be keep simple as possible.
> The getAutorirhies() methods are used only by the specific implementation of
> User named BaseUser, another implementation of User should be free to choose
> another method for handling permissions.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-183) DBUserManager and PropertiesUserManager are not storing the password in the User object after in "authenticate()"
[ https://issues.apache.org/jira/browse/FTPSERVER-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12635691#action_12635691 ] David Latorre commented on FTPSERVER-183: - Niklas, Did you notice this issue? Is there any problem with my solution or some other problems you're foreseeing? > DBUserManager and PropertiesUserManager are not storing the password in the > User object after in "authenticate()" > -- > > Key: FTPSERVER-183 > URL: https://issues.apache.org/jira/browse/FTPSERVER-183 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0-M4 >Reporter: David Latorre >Priority: Minor > Attachments: UserManagers.patch > > > I suppose that as a result of the change in the strategy to encrypt passwords > in DBUserManager, getUserByName() -called by the authenticate() method - > returns an User object with the password field unset. > When trying to use the "save" method , this line throws a > NullPointerException > map.put(ATTR_PASSWORD, > escapeString(passwordEncryptor.encrypt(user.getPassword(; > My reason to use this method is that I call DBUserManager.save() to update > the user in the database with last-login information. > I'm providing a patch although maybe there's a more elegant solution. The > same modification is done in PropertiesUserManager for coherence. > Important Note: with my provided path , the user's password should not be > included in the WHERE query of "updateStatement" as there's a chance that for > a PasswordEncryptor, the result of passwordEncryptor.encrypt is not the > same as the stored password even if matches() returns true. > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-184) IODataConnection ASCII mode does not work as expected.
IODataConnection ASCII mode does not work as expected.
--
Key: FTPSERVER-184
URL: https://issues.apache.org/jira/browse/FTPSERVER-184
Project: FtpServer
Issue Type: Improvement
Reporter: David Latorre
New lines in files sent in ASCII mode are transformed into /r/n no matter
what platform the ftp server is running on. But if I'm not wrong, the new EOL
should be equal to "line.separator" . If ASCII mode is going to be supported,
this ought to be changed.
The code in IODataConnection.transfer()
{
if (isAscii) {
for (int i = 0; i < count; ++i) {
byte b = buff[i];
if (b == '\n' && !lastWasCR) {
bos.write('\r');
}
if (b == '\r') {
lastWasCR = true;
} else {
lastWasCR = false;
}
bos.write(b);
}
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
