[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=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=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)
Re: ftpserver warnings - cannot find an available passive port
Good day, I agree with Emmanuel suggestions on this issue. Still, if you cannot resolve this issue, I think Niklas implemented in the Trunk version some changes on the way passive ports are allocated, so you might want to try that version. 2015-06-30 17:52 GMT+02:00 Michael Benovich m...@hostedftp.com: Hi, We have been running ftpserver 1.0.6 in a production environment for several years. Last week we encountered an issue that we have not encountered before. We began to see intermittent failures when trying to enter passive mode. A review of our logs showed multiple errors (sample trace below) with the warning Failed to open passive data connection... (Cannot find an available passive port). Our configuration includes a passive port range of 800 ports, and based on our internal metrics and netstat output, we do not believe we were using anywhere near this many ports at the time of these errors. Restarting our java application resolved the issue. Are there any known conditions where ftpserver could be consuming a larger number of passive ports than expected? If so, what is the recommended approach to detect and resolve? Many thanks, Mike Detailed error trace: Jun 25, 2015 12:07:03 PM org.apache.ftpserver.command.impl.PASV execute WARNING: Failed to open passive data connection org.apache.ftpserver.DataConnectionException: Cannot find an available passive port. at org.apache.ftpserver.impl.IODataConnectionFactory.initPassiveDataConnection(IODataConnectionFactory.java:170) at org.apache.ftpserver.command.impl.PASV.execute(PASV.java:73) at org.apache.ftpserver.impl.DefaultFtpHandler.messageReceived(DefaultFtpHandler.java:210) at org.apache.ftpserver.listener.nio.FtpHandlerAdapter.messageReceived(FtpHandlerAdapter.java:61) at org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:716) at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434) at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:46) at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:796) at org.apache.ftpserver.listener.nio.FtpLoggingFilter.messageReceived(FtpLoggingFilter.java:85) at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434) at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:46) at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:796) at org.apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:75) at org.apache.mina.filter.logging.MdcInjectionFilter.filter(MdcInjectionFilter.java:136) at org.apache.mina.filter.util.CommonEventFilter.messageReceived(CommonEventFilter.java:70) at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434) at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:46) at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:796) at org.apache.mina.filter.codec.ProtocolCodecFilter$ProtocolDecoderOutputImpl.flush(ProtocolCodecFilter.java:427) at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:245) at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434) at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:46) at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:796) at org.apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:75) at org.apache.mina.core.session.IoEvent.run(IoEvent.java:63) at org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.runTask(OrderedThreadPoolExecutor.java:780) at org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.runTasks(OrderedThreadPoolExecutor.java:772) at org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.run(OrderedThreadPoolExecutor.java:714) at java.lang.Thread.run(Thread.java:722) Jun 25, 2015 12:07:03 PM org.apache.mina.filter.logging.LoggingFilter log INFO: SENT: 425 Can't open passive connection.
[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] [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] [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-tabpanelfocusedCommentId=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
Re: NIO UDP server, does it make sense at all ?
I agree with Emmanuel here. Anyway, if we can have your implementation as the default and all the tests are passed , maybe it's a good idea to do so . Of course, feel free to disregard my opinion :) I just wanted to provide some feedback since you did such an amazing job. 2013/5/30 Emmanuel Lécharny elecha...@gmail.com: Le 5/30/13 9:30 PM, Julien Vermillard a écrit : lazy consensus ? :) Well, right now, I would rather keep it. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: Apache FTP Server - Strange Behavior when passive port specification is explicit
Hello Jagtar, Please, use the ftpserver-users mailing list for these questions. Your log file says that the remote peer (either your FTP client or some network appliance) closed the connection. It is possible that the IP address from the PASV response is incorrect: Entering Passive Mode (ex,te,rnl,ip,203,135) Is ex,te,rnl,ip, the correct IP address the client should connect to? You said the FTP client never got this response so a firewall might be killing the connection for any reason. Check your FTP client (just in case) and Firewall log files. In Active Mode, the ports should be opened in the FTP Client end; the ftpserver only needs port 21 and outgoing connections from port 20 (or the one you have configured in the XML), this is why it works. Active mode is 'troublesome' when the port the FTP client opened in its local computer is not available to the FTP server (ie, the FTP client is behind a firewall or in a NATed environment). 2013/3/31 Jagtar Singh jsmun...@hotmail.com Hi, We configured apache ftp server (v 1.0.6) for passive mode operation. Server is behind firewall so we specified port range (5-55000) asking firewall admin to open the same range.On client side (connecting via external ip) we don't get response to PASV command (when doing dir). On server side we get this exception in log (excerpt below). We thought it's a firewall issue. Strangely, we removed passive configuration from xml and everything started to work. Ports being used were 6+ which we didn't ask admins to open. Also from internal IP, it never gave any issue. Please explain the behavior because mostly we need passive port specification due to restrictive firewalls. I'm afraid this might cause problem. Thanks in advance.J.--[ INFO] 2013-03-28 04:40:53,825 [admin] [][cl.ie.nt.ip] RECEIVED: PASV[DEBUG] 2013-03-28 04:40:53,825 [admin] [][cl.ie.nt.ip] Initiating passive data connection[DEBUG] 2013-03-28 04:40:53,826 [admin] [][cl.ie.nt.ip] Opening passive data connection on address /int.ern.al.ip and port 52103[DEBUG] 2013-03-28 04:40:53,826 [admin] [][cl.ie.nt.ip] Passive data connection created on address /int.ern.al.ip and port 52103[DEBUG] 2013-03-28 04:40:53,827 [admin] [][cl.ie.nt.ip] Firing a WRITE event for session 2[DEBUG] 2013-03-28 04:40:53,828 [admin] [][cl.ie.nt.ip] Firing a WRITE event for session 2[DEBUG] 2013-03-28 04:40:53,828 [admin] [][cl.ie.nt.ip] Event WRITE has been fired for session 2[DEBUG] 2013-03-28 04:40:53,828 [admin] [][cl.ie.nt.ip] Firing a WRITE event for session 2[DEBUG] 2013-03-28 04:40:53,829 [admin] [][cl.ie.nt.ip] Firing a MESSAGE_SENT event for session 2[DEBUG] 2013-03-28 04:40:53,829 [admin] [][cl.ie.nt.ip] Adding event MESSAGE_SENT to session 2Queue : [MESSAGE_SENT, ] [DEBUG] 2013-03-28 04:40:53,829 [admin] [][cl.ie.nt.ip] Event MESSAGE_SENT has been fired for session 2[DEBUG] 2013-03-28 04:40:53,829 [admin] [][cl.ie.nt.ip] Firing a EXCEPTION_CAUGHT event for session 2[DEBUG] 2013-03-28 04:40:53,830 [admin] [][cl.ie.nt.ip] Adding event EXCEPTION_CAUGHT to session 2Queue : [MESSAGE_SENT, , EXCEPTION_CAUGHT, ] [DEBUG] 2013-03-28 04:40:53,830 [admin] [][cl.ie.nt.ip] Event EXCEPTION_CAUGHT has been fired for session 2[DEBUG] 2013-03-28 04:40:53,830 [admin] [][cl.ie.nt.ip] Firing a SESSION_CLOSED event for session 2[DEBUG] 2013-03-28 04:40:53,830 [admin] [][cl.ie.nt.ip] Adding event SESSION_CLOSED to session 2Queue : [MESSAGE_SENT, , EXCEPTION_CAUGHT, , SESSION_CLOSED, ] [DEBUG] 2013-03-28 04:40:53,830 [admin] [][cl.ie.nt.ip] Event SESSION_CLOSED has been fired for session 2[DEBUG] 2013-03-28 04:40:53,830 [admin] [][cl.ie.nt.ip] Event WRITE has been fired for session 2[DEBUG] 2013-03-28 04:40:53,831 [admin] [][cl.ie.nt.ip] Event WRITE has been fired for session 2[DEBUG] 2013-03-28 04:40:53,831 [admin] [][cl.ie.nt.ip] Event MESSAGE_RECEIVED has been fired for session 2[DEBUG] 2013-03-28 04:40:53,831 [] [][] Event MESSAGE_RECEIVED has been fired for session 2[DEBUG] 2013-03-28 04:40:53,831 [] [][] Firing a MESSAGE_SENT event for session 2[DEBUG] 2013-03-28 04:40:53,831 [admin] [][cl.ie.nt.ip] Firing a MESSAGE_SENT event for session 2[ INFO] 2013-03-28 04:40:53,831 [admin] [][cl.ie.nt.ip] SENT: 227 Entering Passive Mode (ex,te,rnl,ip,203,135) [DEBUG] 2013-03-28 04:40:53,831 [admin] [][cl.ie.nt.ip] Event MESSAGE_SENT has been fired for session 2[DEBUG] 2013-03-28 04:40:53,831 [] [][] Event MESSAGE_SENT has been fired for session 2[DEBUG] 2013-03-28 04:40:53,831 [] [][] Firing a EXCEPTION_CAUGHT event for session 2[DEBUG] 2013-03-28 04:40:53,831 [admin] [][cl.ie.nt.ip] Firing a EXCEPTION_CAUGHT event for session 2[ WARN] 2013-03-28 04:40:53,833 [admin] [][cl.ie.nt.ip] EXCEPTION :java.io.IOException: An existing connection was forcibly closed by the remote host at sun.nio.ch.SocketDispatcher.read0(Native Method) at sun.nio.ch.SocketDispatcher.read(Unknown Source) at
[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-tabpanelfocusedCommentId=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
Re: How to rename on complete
Hello, I would say sebb's answer is the easiest way to go. If this is not a solution for you, there are several possible solutions: - You can implement your own version of STOR/STOU commands and invoke the rename there. Done this, it works but I prefer sebb's solution. - You can develop a Filesystem implementation which locks files. Never tried this, but should work. - Don't lock or rename files, just change the 'client' which is reading the incomplete files. We integrate different channels, not only FTP, so we always do this. Whenever we find a new file we store the size and timestamp and we wait for some time to check if the file has been changed. When we detect that the file isn't being changed anymore, we process it. Would that be enough for you ? 2012/5/28 sebb seb...@gmail.com On 24 May 2012 01:44, Charles W. Stanton cwstan...@gmail.com wrote: I just downloaded the Mina source code and am looking through it. What I'd like is a way to have the Mina sftp server accept and save a file to one name, like originalName_tmp, then change the name to originalName after the transfer is complete. That way I can have an external process watching the directory know for sure when the transfer is done. Right now I'm grabbing partial files, even if I try to get a read lock. (Stupid Java...) Any quick thoughts? Is there an easy way to plug in to the Mina architecture? Or override a class? Or... Use the client to ask the server to rename the file once it has been uploaded? Note that the code will need to allow for the case where the rename fails.
Re: Welcome Sebastian Bazley as a MINA committer
Welcome sebb! 2011/3/27 Emmanuel Lecharny elecha...@gmail.com: On 3/27/11 10:18 PM, Bernd Fondermann wrote: On 27.03.11 21:37, Niklas Gustavsson wrote: Hi The MINA PMC has voted to invite Sebastian Bazley (apache ID sebb) as a MINA committer due to his great bug reports and patches for FtpServer. Welcome Sebb! +1, indeed! Yeah, welcome ! -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: Configuring a custom UserManager
2010/11/11 John Hartnup john.hart...@gmail.com: OK, I've explained the issue. I was looking at the 1.1.0 SNAPSHOT source, while running the stable 1.0.5 code. 1.0.5 does not use the dynamically configured CommandFactory for SITE commands. Is there some sort of guesstimate as to when 1.1.0 will become a stable release? Maybe Niklas can give you an estimate, but there have been few changes for 1.1.x ... On 11 November 2010 14:27, John Hartnup john.hart...@gmail.com wrote: Hi again, On a similar note, I'm having trouble getting a custom SITE command in Apache ftpserver to work. commands command name=SITE_PARM spring:bean class=org.john.ftps.command.SITE_PARM/ /command /commands I can see (via logging) that the SITE_PARM object is constructed, but when I send the site parm ftp command, I get a 502 error, suggesting that the CommandFactory has not returned the object. Any suggestions? (By the way, is this the right mailing list to ask such questions?) I think the users mailing list was a more appropriate choice in your case. Note that FTPServer 'dev' list is the same as MINA developers list so I recommend that you use the prefix [FTPSERVER] or similar when you want to ask anything specific to FTPServer. Thanks, John -- There is no way to peace; peace is the way -- There is no way to peace; peace is the way
Re: [SSHD] SFTP does not support v3
2010/8/3 Thomas Charron twaf...@gmail.com: On Thu, Jul 29, 2010 at 10:10 AM, Andreas Johansson fri.radi...@gmail.com wrote: Hi, The current SFTP implementation in SSHD does not support v3 (Section 7) of the standard which the widely used JSch client currently only support. The issue is in section 9.3 of the v6 standard: bool end-of-file [optional] The last byte end-of-file corrupts the datastream when used with the JSch client and since it's optional I would like to disable/remove it from the SSHD code to support more clients. What do you think? Curiouse, if the client doesn't support it, why, exactly, is it a bug in the server when the specification clearly shows it as being optional, (aka, the servers choice)? I partially agree with Thomas here, it is not Mina SSHD that doesn't correctly support the standard but Jsch. I would try to open in issue so they add support for this EOF character. Still, It is true that JSCH is widely used in java environments so I would suggest that we add a configuration parameter so the use of an EOF delimiter can be activated/deactivated. We should then check if the default must be no eof or please, eof :) Are you ok with this, Andreas? You can open a JIRA issue in that case - I would advice against just removing the EOF delimiter as it is possible that some other clients do expect this byte and start failing if we remove it :) -- -- Thomas
Re: Conexão mina com banco de dados
Hello Diego,
It seems that the xml has been processed to avoid XSS attacks :-)
Still, I don't see the tags enclosing the update-user, insert-user
SQL sentences... My suggestion is that you revert any changes to
ftpd-full.xml and once the server starts, you can Carefully edit the
file until it's fully configured :)
2010/7/23 Diego Silva e Silva di...@zimbra.gam.com.br:
Obrigado por responder,
não estou conseguindo entender a estrutura... meu arquivo xml que estou
passando como parametro esta da seguinte forma:
xml version=1.0 encoding=UTF-8 ?
-
server xmlns=http://mina.apache.org/ftpserver/spring/v1;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://mina.apache.org/ftpserver/spring/v1
http://mina.apache.org/ftpserver/ftpserver-1.0.xsd; id=myServer
listeners
name=default port=21
ssl
keystore file=./res/ftpserver.jks
password=password /
ssl
listeners
salted
beans:bean
class=org.apache.commons.dbcp.BasicDataSource
beans:property name=driverClassName
value=com.mysql.jdbc.Driver /
beans:property name=url
value=jdbc:mysql://localhost/ftpd /
beans:property name=username value=myuser /
beans:property name=password value=secret /
beans:bean
INSERT INTO FTP_USER (userid, userpassword,
homedirectory, enableflag, writepermission, idletime,
uploadrate,
downloadrate) VALUES ('{userid}', '{userpassword}',
'{homedirectory}',
'{enableflag}', '{writepermission}', {idletime},
{uploadrate},
{downloadrate})
UPDATE FTP_USER SET
userpassword='{userpassword}',homedirectory='{homedirectory}',enableflag={enableflag},writepermission={writepermission},idletime={idletime},uploadrate={uploadrate},downloadrate={downloadrate}
WHERE userid='{userid}'
DELETE FROM FTP_USER WHERE userid = '{userid}'
SELECT userid, userpassword, homedirectory,
enableflag, writepermission, idletime, uploadrate,
downloadrate FROM
FTP_USER WHERE userid = '{userid}'
SELECT userid FROM FTP_USER ORDER BY userid
is-adminSELECT userid FROM FTP_USER WHERE userid='{userid}'
AND
userid='admin'is-admin
authenticateSELECT userpassword from FTP_USER WHERE
userid='{userid}'authenticate
server
mas na inicialização do servidor passando esse arquivo como parametro me
retorna o seguinte erro:
C:\buffer\JFtpServer\apache-ftpserver-1.0.4\binftpd.bat
c:\buffer\JFtpServer\ap
ache-ftpserver-1.0.4\res\conf\ftpd-full.xml
Using XML configuration file
c:\buffer\JFtpServer\apache-ftpserver-1.0.4\res\con
f\ftpd-full.xml...
org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line
59 i
n XML document from file
[c:\buffer\JFtpServer\apache-ftpserver-1.0.4\res\conf\f
tpd-full.xml] is invalid; nested exception is org.xml.sax.SAXParseException:
cvc
-complex-type.2.4.d: Invalid content was found starting with element
'beans:prop
erty'. No child element is expected at this point.
at
org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadB
eanDefinitions(XmlBeanDefinitionReader.java:404)
at
org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBea
nDefinitions(XmlBeanDefinitionReader.java:342)
at
org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBea
nDefinitions(XmlBeanDefinitionReader.java:310)
at
org.springframework.beans.factory.support.AbstractBeanDefinitionReade
r.loadBeanDefinitions(AbstractBeanDefinitionReader.java:143)
at
org.springframework.beans.factory.support.AbstractBeanDefinitionReade
r.loadBeanDefinitions(AbstractBeanDefinitionReader.java:178)
at
org.springframework.beans.factory.support.AbstractBeanDefinitionReade
r.loadBeanDefinitions(AbstractBeanDefinitionReader.java:149)
at
org.springframework.beans.factory.support.AbstractBeanDefinitionReade
r.loadBeanDefinitions(AbstractBeanDefinitionReader.java:212)
at
org.springframework.context.support.AbstractXmlApplicationContext.loa
dBeanDefinitions(AbstractXmlApplicationContext.java:113)
at
org.springframework.context.support.AbstractXmlApplicationContext.loa
dBeanDefinitions(AbstractXmlApplicationContext.java:80)
at
org.springframework.context.support.AbstractRefreshableApplicationCon
text.refreshBeanFactory(AbstractRefreshableApplicationContext.java:123)
at
org.springframework.context.support.AbstractApplicationContext.obtain
Re: [FtpServer] FindBugs found 4 bugs in ftpserver
Welcome Back Sergey! Just a little question: *If session.getRemoteAddress() is not instanceof InetSocketAddress,* Is that really possible with our current code? 2010/6/11 Niklas Gustavsson nik...@protocol7.com: On Wed, Jun 9, 2010 at 4:09 PM, Sergey Vladimirov vlser...@gmail.com wrote: 4 errors were found by FindBugs in main ftpserver code: I think all four of these deserves a JIRA issue. That way we won't forget to fix them. Would you mind adding them? P.S.: I'm back for ftpserver for a while (have about 6 month) :) Welcome back! /niklas
[jira] Commented: (FTPSERVER-369) maxLogin is reached immediately
[
https://issues.apache.org/jira/browse/FTPSERVER-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] 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] 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=revrev=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] 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.
Re: svn commit: r942690 - in /mina/ftpserver/trunk/core/src: main/java/org/apache/ftpserver/impl/FtpIoSession.java test/java/org/apache/ftpserver/clienttests/LoginTest.java
Oh sorry, I believed I was using MINA formatter so I thought it would be ok to format the whole thing. Let me check if this happened for both commits and i'll fix the issue. 2010/5/10 Niklas Gustavsson nik...@protocol7.com: On Mon, May 10, 2010 at 11:03 AM, d...@apache.org wrote: Author: dlat Date: Mon May 10 09:03:00 2010 New Revision: 942690 URL: http://svn.apache.org/viewvc?rev=942690view=rev Log: FTPSERVER-369 maxLogin is reached immediately. REIN command is not decreasing the login count. There's a lot of formating changes in this commit. Do you have a patch of the real change? /niklas
Re: svn commit: r942690 - in /mina/ftpserver/trunk/core/src: main/java/org/apache/ftpserver/impl/FtpIoSession.java test/java/org/apache/ftpserver/clienttests/LoginTest.java
So, what do you want me to do Niklas? I got a new file with only the
code changes ... should I commit this? For it would show a lot of
differences with the previous file as well, or do you just want the
patch file in order to see the differences...
Btw I used winmerge to generate the patch file and I don't know if
this is the expected format ... It generated this file:
648d647
logoutUser();
655,667d653
}
public void logoutUser() {
ServerFtpStatistics stats = ((ServerFtpStatistics) context
.getFtpStatistics());
if (stats != null) {
stats.setLogout(this);
org.slf4j.LoggerFactory.getLogger(this.getClass())
.debug(Statistics login decreased due to user logout);
} else {
org.slf4j.LoggerFactory.getLogger(this.getClass())
.warn(Statistics not available in session, can not decrease
login count);
}
2010/5/10 Emmanuel Lecharny elecha...@gmail.com:
On 5/10/10 11:41 AM, David Latorre wrote:
Oh sorry,
I believed I was using MINA formatter so I thought it would be ok to
format the whole thing.
It would be a good idea to reformat all the files following the current
formater in one big commit, so that developpers are not annoyed when
checking a diff...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com
[jira] Commented: (FTPSERVER-369) maxLogin is reached immediately
[
https://issues.apache.org/jira/browse/FTPSERVER-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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.
Re: Spring Integration
My opinion was similar to the one stated by Emmanuel and thus my advice to Andreas... I agree that a 'more usable code' is desirable (even if you are not using any DI container, it's nice to know beforehand how you should create an object) but only as long as we don't have to call the needed changes tweaks :-) 2010/4/20 Guillaume Nodet gno...@gmail.com: I somewhat disagree. I agree we should not be spring specific (i.e. including specific annotations or interfaces), but providing setters or cleaner init methods should be considered in order to make the code more usable. On Sat, Apr 17, 2010 at 09:47, Emmanuel Lecharny elecha...@gmail.comwrote: On 4/7/10 2:06 PM, David Latorre wrote: Hello Andreas, I don't think this has been discussed for MINA3 yet but it should be sometime in the future. For Mina 2.0 I guess your best option would be to write wrapper classes - and you can provide patches for these, of course. IMHO, and regarding to the recent past, we should never tweak the code in order to make it Spring ready. The reason is that in 2011, August Framework will get out, meet its audience, and make geeks asking about August integration... The wrapper approach is the way to go. We could provide a specific jar containing all those Sping wrappers, then next year an other one for August support, before leaves start to fell... -- Regards, Cordialement, Emmanuel Lécharny www.nextury.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Spring Integration
Hello Andreas, I don't think this has been discussed for MINA3 yet but it should be sometime in the future. For Mina 2.0 I guess your best option would be to write wrapper classes - and you can provide patches for these, of course. 2010/4/7 Andreas Sahlbach andr...@sahlbach.com: Well, that depends on my coding style, I guess. :-) But the reason for my question is, that there is no simple right or wrong answer. It's possible to extend the class to provide support for spring or to write a wrapper class to decouple the spring support from the core classes. So I just want to know the overall strategy regarding spring. And then it's no problem to provide patches. On Wed, Apr 7, 2010 at 10:50 AM, Norman Maurer norman.mau...@googlemail.com wrote: Hi Andreas, I'm not a mina dev but I'm sure they love patches which make the code more usable ;) Bye, Norman 2010/4/7 Andreas Sahlbach andreas.sahlb...@gmail.com: Hi guys! I am a new user of your framework (great stuff!) and I have a short question regarding the spring framework. I am using mina 2.x and noticed that you removed a lot of special spring stuff in favor of a more general support for injection frameworks. Still there are a number of classes in the framework that are pretty spring-unfriendly and cannot be used from within spring without user modifications (like extending them or wrapping them). So my question is: What is your midterm plans regarding spring integration? Are you going to modify your classes so that they can be easily from within spring? If so, should I file a bug (with patch) for classes that don't work currently? Or are you going to implement more helper classes in the xbean package? I am referring for example to DemuxingProtocolCodecFactory or DemuxingIoHandler, which can't be initialized easily from within spring. Best regards, Andreas -- Andreas Sahlbach -- Andreas Sahlbach
Re: FTPServer handling of multiple concurrent connections.
2010/3/31 Niklas Gustavsson nik...@protocol7.com: On Wed, Mar 31, 2010 at 6:32 PM, Sai Pullabhotla sai.pullabho...@jmethods.com wrote: Since I did not hear back anything on this, I will ask again :). Are you guys okay with the proposed short term solution? +1 to option 1 and to defaulting to max users. Sounds good :-) /niklas
[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-tabpanelfocusedCommentId=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.
Re: svn commit: r928769 - in /mina/ftpserver/trunk/core/src: main/java/org/apache/ftpserver/config/spring/ main/java/org/apache/ftpserver/ipfilter/ main/java/org/apache/ftpserver/listener/ main/java
Regarding this issue, I downloaded the common formatter for Eclipse from the website a while back and (I think!) I'm using it. I use the 'autoformat' feature all the time so I hope that's the one which should be used for FTPServer as well, is it? Otherwise I think it would be great if we defined one so we can get rid of these problems. 2010/3/29 Sai Pullabhotla sai.pullabho...@jmethods.com: BTW, do you know why Hudson is complaining about the test failure on trunk? I did not get that error locally. Regards, Sai Pullabhotla On Mon, Mar 29, 2010 at 4:06 PM, Niklas Gustavsson nik...@protocol7.com wrote: On Mon, Mar 29, 2010 at 9:39 PM, Emmanuel Lecharny elecha...@gmail.com wrote: Otherwise, if you think that the coding conventions don't fit, then we can discuss openly here. I don't mind what coding conventions we use, as long as they are consistent :-) /niklas
FTPServer handling of multiple concurrent connections.
Hello, When inspecting http://issues.apache.org/jira/browse/FTPSERVER-359 I noticed that we might have an issue with threading in Ftpserver. I think we are using a 'fixed size thread pool' with max-threads=16 for the Executor threadpool in which commands are executed. This would mean that if we had 16 data transfers currently running , FTPServer would be blocked until some of these data transfers ended- Is my understanding correct? Is this behaviour desirable for us? I don't think that 16 data transfers are that many, and some users might need to send huge files.
Re: FTPServer handling of multiple concurrent connections.
2010/3/30 Niklas Gustavsson nik...@protocol7.com: On Tue, Mar 30, 2010 at 10:33 AM, Sai Pullabhotla sai.pullabho...@jmethods.com wrote: I don't think that was intended. If this is in fact an issue, we should probably consider adding a configuration option such as maxThreads as the default max we choose may not be the best in all cases. I think David is correct, and I agree with your proposed solution (defaulting the value higher than 16 thou). We should also look into moving the data connection over to using MINA, if someone got the time. I would rather go for a solution that make it impossible to block FTPServer rather than making it 'more difficult'. For this, we might limit the total number of data connections which wouldn't be perfect but might help... or maybe we can enforce a rule that MaxUsers MaxThreads. Regarding the move of the data connection to MINA, I understand Sai's position that is using blocking-IO here is probably lighter ( It would be nice if we could have the same 'MINA pipeline' accepting on several ports...). Still I see an advantage if we used MINA - filters: - We could have different filters for ASCII mode, binary mode, 'Z' mode or other modes of encoding we or the users might think of (Although it is easy to have custom streams that do this for us with the current implementation). - We can include a fine grained monitoring of current transfers, a filter might inform via JMX or other means of e.g., the amount of data transferred - A filter could limit the quota for a user, for a session, for a week/month for this user in 'real time'. There are other ways to do this as well... - We could have a filter that limited bandwidth usage, although I don't think there is anything like that in FTPServer. Still, several of the possibilities we can think of seem not that useful since we should have multiple 'chains' for data connections. /niklas
[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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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.
Re: Black/White List in FTP Server
2010/3/16 Niklas Gustavsson nik...@protocol7.com: On Tue, Mar 16, 2010 at 2:52 PM, Sai Pullabhotla sai.pullabho...@jmethods.com wrote: If a filter can make use of this event, why not an Ftplet? To me, because writing your own Ftplet should require minimal knowledge of the internals of FtpServer. Compare this to writing a Servlet and your own Valve for Tomcat. /niklas niklas opinion makes sense but, of course, some users might need this sessionCreated event. My suggestion is that we wait until some of the inner workings of MINA 3.0 are agreed upson so we don't have to make a decision based on a threading/event model that is very likely to change. The IPFilter that can act as a blacklist or a whitelist is a pretty clever idea. What about programmatically changing the IPFilter? as if you want to update the blacklist but the whitelist 'version' is in use...
[jira] Commented: (FTPSERVER-349) WhiteList
[ https://issues.apache.org/jira/browse/FTPSERVER-349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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.
Re: [jira] Commented: (FTPSERVER-349) WhiteList
Is there a way to have these emails added to the JIRA discussion? I just created a ticket in MINA filter for this 0.0.0.0/0 feature. 2010/3/8 Niklas Gustavsson nik...@protocol7.com: On Mon, Mar 8, 2010 at 2:27 PM, Sai Pullabhotla sai.pullabho...@jmethods.com wrote: Why not have asterisk(s) represent allow all? I think we should stick to using CIDR notation. 0.0.0.0/0 should work, if it doesn't that's a bug in our current implementation and needs fixing. For my 2 cents, I think a white list filter should work as: * If the list of subnets is empty: allow all IP addresses * As soon as a subnet/IP address is added, only allow for that This would save our users from having to keep track of the state of the filter themselves (and move it in or out ióf the filter chain). /niklas
[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: (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-tabpanelfocusedCommentId=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.
Re: [MINA 3.0] Debugging toolkit
2010/1/25 Alan D. Cabrera l...@toolazydogs.com: On Jan 25, 2010, at 8:21 AM, Ashish wrote: On Mon, Jan 25, 2010 at 9:48 PM, Emmanuel Lecharny elecha...@gmail.com wrote: Alan D. Cabrera a écrit : On Jan 19, 2010, at 7:41 AM, Ashish wrote: Had picked this form one the discussion threads and added to the MINA 3.0 design page, so that we don't loose this. had some initial thoughts around this, like we can some kind of visualization tool build around MINA, which can help us see/debug the MINA based System. One can view number of IoSession's, IoChain's, configuration etc. It could be build as an Eclipse plugin or a standalone UI talking to MINA code via JMX. I am not sure, but we can see if we can extend ProtoTiger as a debugging/visualization tool. These are just some initial thought, will refine the understanding as we progress further with 3.0 design. Any suggestion? I wouldn't classify these as debugging toolkit but a management toolkit; very critical. I was also thinking about the logging discussion that we had earlier and I think that I've come around to the thinking that it's important to provide some kind of logging mechanism who's scope is narrowed to a particular session. (I'm still not sold on the usefulness of a general logging filter such as the one that we have now). With JMX, and a decent tool (something like MX4J : http://mx4j.sourceforge.net/), providing some graphs should be a piece of cake. Emm ! You read my mind. I had something similar in my mind :-) More like number of session, and if possible the chain associated with the same.. there could be more such useful stuff on that UI It would be good if we had some kind of conventions, e.g. naming and event, that other protocols would follow. Being able to track down one single session is also something that a JMX based tool can do. Logs ? That's for post-mortem debugging :/ We use logs extensively when working on production issues where sessions can have the lifetime of subatomic particles. We should carefully consider the usefulness of logging in this toolkit. Logging at the session level should be pretty easy with NDC/MDC, right? The problem is of course, if their logging implementation doesn't support these. Regards, Alan
Re: [MINA 3.0] Which filters should we keep ?
I would agree with Niklas that LoggingFilter is quite useful in FTPServer but of course there are other ways to do it. I didn't follow your discussion too closely so excuse me if I'm wrong. Do you mean that instead of logging e.g, only after the second ProtocolCodecFilter you would log in all the filters all the time? so now, let's say we have 4 filters in our ,i don't know, Mina-based FPClient. Instead of having a filter logging the commands sent (as FTPServer currently does, which is SO useful to track a connection - maybe it's only our customers, but I have to monitor their connections quite often to explain what they did wrong), we would have 4 filters logging probably at the same level so the log file would be cluttered ( or we wouldn't have any logs whatsoever) unless the programmers using MINA logged the communication themselves, is that what you are suggesting? 2010/1/10 Niklas Gustavsson nik...@protocol7.com: On Sun, Jan 10, 2010 at 2:48 PM, Alan D. Cabrera l...@toolazydogs.com wrote: As for the fact that there are two ProtocolCodecFilters, that's not a problem since you will be printing out the thread id in your log. Yes, but under heavy load you only want to log the very minimum you can while still tracking down your problem, therefore you need to be able to switch on logging at a very specific point in the filter chain. Besides, I'll bet LoggingFilter is, with ProtocolCodecFilter and maybe ExecutorFilter, by far the most used filters by our users. Just because it's a widespread bad habit.. ;) Tastes differ I presume :-) /niklas
Re: Looking for ideas on building a DMZ Gateway
Hello Sai, I'm no expert here so i cannot give you advice on your solution but ... are you sure you need all of this? I'm thinking it should be possible to meet your security needs in an simpler way. Let's say, application-based firewalls on the dmz machines? (so only the allowed applications can't connect to the network) A more secure way to do this, I guess, could be running the services in VMware, VirtuaBox or any other virtualization software. Another option could be some kind of VLAN with security ... Anyway , your solution might be completely right depending on your circumstances. It's my understanding that you want a proxy server routing e,g. all the incoming FTPS requests to the actual service inside your private network - this is very easy to implement with MINA if you don't have this 'no new connections from the DMZ' restriction(actually I did), but even if you used any kind of notification system to alert the other end that a new connection should be created I think this might be troublesome ; how do we change FTPServer to indicate that we should create the connection to the 'client' (or proxy) and not the other way? And is it worthy? If you didn't need such a general solution, I guess a JMS server or similar solutions ( I wonder if it's possible to do something like this with XMPP) could work. You would send messages to a local queue (or local endpoint of any kind) that would be read by the machines in the internal network. 2009/12/18 Ashish paliwalash...@gmail.com: In fact most of the requests come from external network over the Internet. The idea is if a hacker makes it into the DMZ, he should not be able to open any connections to the internal network. Therefore, the firewall sitting between the DMZ and internal network is configured to block all incoming connections to the internal network, but allows connections to the DMZ from the internal network. As said before, systems in the DMZ will not contain any data of any sort, so there is not much for the hacker out there. Security is very important, but it seems like a situation I want to host a Web Server, but nobody from outside can open a connection :-( There are ways to address security concerns. Here is what I'm thinking... The Services (FTP/S, SFTP, HTTP/S) in the internal network need to know their DMZ gateways/proxies. During startup of these services, they initiate a connection or a few connections to the DMZ Gateway. These connections can later be used for bi-directional communication between the server in the DMZ and the actual Service sitting in the internal network. When a connection from external client comes in, it is routed to the system in the DMZ. At this point, the DMZ already has pre-established connection(s) so it can send some messages to the internal network such as a new client just connected. Based on the message the DMZ sends, the internal network may open one or more connections. Here you are talking about Connection pooling from internal network and DMZ :-) I You can actually use this to transfer data between *m* client with *n* connections where m n The tricky part is you don't want to initiate connection from DMZ. May be DMZ machine could delegate the Connection auth check to soemone in internal network, and if auth is successful allow the connection from Proxy to internal network. By any chance, is it a possibility that you allow connect request only from known IP's to your machine in DMZ? As far as Proxying goes, it is probably going to be a lot easier for HTTP/SFTP, but for FTP/FTPS, the data connection handling could become tricker. In order to handle the data connection in FTP, this Gateway must also filter the packets sent/received. Is that correct? Hope this all makes sense. I've read somewhere on the Internet that this kind of thing can be accomplished with reverse-proxying. Do you guys have any idea on what it means and how it can be implemented. I appreciate any other ideas that you may come up with. Not an expert on this :-( Would be interesting to see your product come to life :-) thanks ashish
Re: Version 2.x - Norweigian Wood
2009/12/4 Trustin Lee (이희승) trus...@gmail.com: On 2009/12/04 9:25 pm, Emmanuel Lecharny wrote: Glenn Ivar Klausen a écrit : Emmanuel LŽcharny wrote: Well, less than dead wood... This name was picked by someone who was at the origin of the project, at a time he was pretty alone working on it (since then, he quit). I personnaly don't think it's a good idea to attach a name with a version, à la Ubuntu (I have always been totally lost with Intrepid Jakal or Laughable Vampire, not being able to make a connection with 8.04 or 9.10). Anyway, I think we should get rid of those useless nicknames. Ok, ... I was just referring to the fact that Norwegian is spelled wrong, however, its a good point regarding the nick names. G (Norwegian) Wikipedia, about Norwegian wood : This exchange took place in a press conference in Los Angeles on 24 August 1966: Reporter: I'd like to direct this question to messrs. Lennon and McCartney. In a recent article, Time magazine put down pop music. And they referred to Day Tripper as being about a prostitute... Paul: Oh yeah. Reporter: ...and Norwegian Wood as being about a lesbian. Paul: Oh yeah. :) It actually means a novel with the same title [1]. Other code names are also the titles of Haruki's novels. The code names were never announced anyway. Feel free to remove it from JIRA. I'd be glad to take it over to Netty [2]. What a great novelist he is :-) To my mind, having our 'nickames' based on Haruki's novels instead of what's usual in other projects (I won't give any examples ...) is something to be proud of :P But it is true that version numbers are much more useful so .. whatever. Otherwise I would suggest sputnik as a new nickname (and goal) for next MINA version. That's from Sputnik, my love by Murakami, of course. I'm sorry that no one seemed to notice the misspelling, Glen, but these things happen from time to time, my apologies :P Btw in Spain, they coined their own title for this novel, although it is in English! Tokio Blues ( Ok, so not English either as they don't say Tokyo but definitely not Spanish). Trustin [1] http://en.wikipedia.org/wiki/Norwegian_Wood_(novel) [2] http://www.jboss.org/netty/
[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-tabpanelfocusedCommentId=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.
Re: [jira] Commented: (FTPSERVER-287) NLST: Implementation only supports listing files in working directory [patch provided]
I had a look and I'm inclined to think that the request is we return the full pathname :-) 2009/6/1 Niklas Gustavsson (JIRA) j...@apache.org: [ https://issues.apache.org/jira/browse/FTPSERVER-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12715024#action_12715024 ] Niklas Gustavsson commented on FTPSERVER-287: - I've worked some on this and wrote some test cases (I had some troubles following along in the provided patch). Comparing with your examples above, we seem to return the correct reply for whatever path I throw at it. However, return only the file name, not the full path. The RFC says The server will return a stream of names of files and no other information. which seem like we might be doing the correct (or at least acceptable) thing when returning only the file names. The test case has been added in trunk in core/src/test/java/org/apache/ftpserver/clienttests/NLSTTest.java. I'm assuming I'm missing something so please help me along :-) NLST: Implementation only supports listing files in working directory [patch provided] -- Key: FTPSERVER-287 URL: https://issues.apache.org/jira/browse/FTPSERVER-287 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.1 Environment: Fedora 10-64bit and RH 5.2-64bit, Java 1.6.0_12-64 Reporter: Dennis Keller Fix For: 1.0.2, 1.1 Attachments: nlst.patch The NLST formatter, as implemented on trunk is insufficient to handle any request other than a file within in the current working directory. Some examples: ftp passive Passive mode on. ftp nlist /directory/file.txt 227 Entering Passive Mode (127,0,0,1,179,241) 150 File status okay; about to open data connection. file.txt 226 Closing data connection. Other FTP servers return the following: ftp passive Passive mode on. ftp nlist /directory/file.txt 227 Entering Passive Mode (127,0,0,1,179,241) 150 File status okay; about to open data connection. /directory/file.txt 226 Closing data connection. Upon investigating, I found that the formatter will not handle absolute file requests, parent directory request or non-absolute child directory requests. It does not error, it just doesn't give useful output. I've modified the code to handle the cases that I could come up with, but there may be other situations that need to be covered. I'm not an expert on the FTP specification (but what I could find was not impressive), so there many be additional cases that need to be covered. Please consider the attached patch, with accompanying test cases -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] 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] 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-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.
Re: [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.
2009/5/28 Niklas Gustavsson nik...@protocol7.com: Sorry, my bad, I mixed up \r and \n. Let me rephrase: 1. If we get sent a \n only, should we print EOL or \n? Since \n is not the canonical line ending in the RFC, we might not want to treat this as a line ending that we should convert into the local line ending. 2. if we get sent a \r\n, we should clearly print EOL 3. If we get sent a \r only, we currently print EOL. Given the argument above, is this correct? Oh sorry I didn't understand you before, that's of course another option - we only transform the canonical line ending and leave the rest as is. I don't know what are the advantages / caveats of those options though. Your proposal seems to be more strict to the standard and thus, most preferrable. But in practice, this could mean that sending the very same file from commons-ftp will result in a different file than if you sent it from filezilla (I don't know if clients take the filezilla approach - just convert the system's line ending or they do as commons-ftp, convert all of them). But I guess this is not an issue, they're just line ending in the end ... The discussion about the correctness of Filezilla in its interpretation to the RFC is not conclusive either. RFC says: The sender converts the data from an internal character representation to the standard 8-bit NVT-ASCII , just an internal representation, not the internal represention for its system ... So unless someone has a strong reason to need uniform EOLs corresponding to the target system, then we might assume that the issue with different clients resulting in different files can be ignored, and transform only the canonical line ending. By the way, do we support REST when using ASCII mode? I would say no, but i'm not checking the code right now. /niklas On Thu, May 28, 2009 at 12:13 AM, David Latorre dvl...@gmail.com wrote: 2009/5/27 Niklas Gustavsson nik...@protocol7.com: On Wed, May 27, 2009 at 3:07 PM, David Latorre dvl...@gmail.com wrote: I added a fix and some tests but ToNetASCIIOutputStream in commons-util will always replace to \r\n so I'm uploading a modified version. With this fix ascii mode should not eat line separators anymore. Thanks! Looking into the fix I'm not sure we should print EOL on \r. Since \r is not the canonical line ending in the RFC, I think we should rather print \r as it is in the stream. What do you think? I don't really know if \r has other users than being part of the New Line sequence. I guess \r could take us back to the beginning of the line ... but it doesn't make much sense in a file. My reasons to leave \r as the character substituted by EOL are 1) Because it was previously written in that way. 2) Mac OS 9 and before had \r as the new line separator, so if the line endings of a Mac OS 9 text file weren't transformed to \r\n and we were ignoring \r , we would swallow the new line again. On the other hand, if we write the \r character, we cannot transform to Unix line endings which have no \r... So, I'm sure there are other options and they might be more performant, but this solution seems to work in several situations which are usually not supported and the code is fairly easy to understand ... Of course, for me , the best solution is to entirely remove the ASCII mode from the RFC :-D /niklas
Re: [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.
I added a fix and some tests but ToNetASCIIOutputStream in commons-util will always replace to \r\n so I'm uploading a modified version. With this fix ascii mode should not eat line separators anymore. 2009/5/26 Niklas Gustavsson nik...@protocol7.com: On Tue, May 26, 2009 at 12:38 PM, Sai Pullabhotla sai.pullabho...@jmethods.com wrote: 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. Hmm... shouldn't it be just doing the following: 1. Replace \r\n with System.getProperty(line.separator); 2. Write everything else as is. Agreed. However, that's not what we currently do since if the client only sends \n we will strip out the line ending. This is a bug on our side that we should fix. You can probably agrue that FileZilla is doing the right thing as \r is probably not to be regarded as the internal character representation (as described in the RFC) on Windows. Anyways, we should add a bunch of tests for this and fix. /niklas
[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] 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] 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-tabpanelfocusedCommentId=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] 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] 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] 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-tabpanelfocusedCommentId=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.
Re: [VOTE] Releasing FtpServer 1.0.1
2009/5/17 Niklas Gustavsson nik...@protocol7.com: On Wed, May 13, 2009 at 10:56 PM, Niklas Gustavsson nik...@protocol7.com wrote: since 1.0.0 some issues has been reported in FtpServer. Now is therefore a good time to get 1.0.1 out. This vote passed with the following result: 3 binding +1: Emmanuel Lecharny Julien Vermillard Niklas Gustavsson 2 non-binding +1: Ashish Sai Pullabhotla (I'm guessing Davids vote http://markmail.org/message/wqukhzsle7tlytf6 was really for the thread, but not counting it) Yeah sorry, I had some issues at work and forgot to send the email. And, it wasn't really necessary... I noticed that the downloads page is not updated at cwiki: http://cwiki.apache.org/FTPSERVER/downloads.html Maybe it is still pending but I preferred to warn you in case anything unexpected happened :-) I'll start performing the release right away. Thanks for voting! /niklas
[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] 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] 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.
Re: before the release of FtpServer 1.0.1 ...
+1 2009/5/14 Niklas Gustavsson nik...@protocol7.com: On Thu, May 14, 2009 at 11:09 AM, Emmanuel Lecharny elecha...@apache.org wrote: Can't we remove the @version tags and change the @author tags to @author a href=http://mina.apache.org/ftpserver;Apache FTPServer Project/a before the release ? It's a one hour task, which won't impact the way the server works at all. Better do it now, no ? It seemed to be low prio, so I did it after branching 1.0.1. /niklas
Re: before the release of FtpServer 1.0.1 ...
Uh, Sorry, too many windows open. 2009/5/14 David Latorre dvl...@gmail.com: +1 2009/5/14 Niklas Gustavsson nik...@protocol7.com: On Thu, May 14, 2009 at 11:09 AM, Emmanuel Lecharny elecha...@apache.org wrote: Can't we remove the @version tags and change the @author tags to @author a href=http://mina.apache.org/ftpserver;Apache FTPServer Project/a before the release ? It's a one hour task, which won't impact the way the server works at all. Better do it now, no ? It seemed to be low prio, so I did it after branching 1.0.1. /niklas
Re: Got some error when compiling SSHd
2009/5/7 Bernd Fondermann bf_...@brainlounge.de: Hi Emmanuel, this is a known (at least to me) problem with mvn on wndws. Just make sure that the text file is deleted. I suffer this 2/5 of the times I run the tests under windows. Not necessarily using maven. A solution anyone? HTH, Bernd Emmanuel Lecharny wrote: Sorry for the lack of information. I was in a hurry, didn't had time to copy/paste the log. Here is what I get on a slow windows machine : ... [ERROR] BUILD ERROR [INFO] [INFO] Failed to delete directory: C:\mina\sshd\sshd-core\target. Reason: Unable to delete file C:\mina\sshd\sshd-core\target\surefire-reports\org.apache.sshd.C lientTest.txt [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 10 seconds [INFO] Finished at: Thu May 07 15:48:20 CEST 2009 [INFO] Final Memory: 9M/17M [INFO] On Thu, May 7, 2009 at 12:33 PM, Guillaume Nodet gno...@gmail.com wrote: It works for me too. Please post some details. On Thu, May 7, 2009 at 12:20, Bernd Fondermann bf_...@brainlounge.de wrote: Emmanuel Lecharny wrote: Hi guys, just before leaving for a long week-end, I tried to build all the MINA code. I get some error when compiling sshd. Can someone check ? Thanks ! mvn install works fine for me. What about a helpful error description! What do you do? What error do you get? Thanks, and: Have fun! Bernd -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Bernd Fondermann is a new MINA commiter
Welcome Bernd! 2009/4/20 Bernd Fondermann bf_...@brainlounge.de: Niklas Gustavsson wrote: All, as part of the move of Vysper from Apache Labs to MINA, the MINA PMC has voted Bernd Fondermann in as a MINA committer. Let's all welcome Bernd into the world of MINA! /niklas Thank you all for your trust. Bernd
Re: [Discuss] Is it ok to share other information(not related to project) with community?
2009/4/20 Ashish paliwalash...@gmail.com: Folks, I received an offer mail from Atlassian. Its real good one and was confused whether I can share it here or not, as its a product sale offer from a company. I wonder if this offer would have any sense for us. It might be 'a special offer' we're not eligible for. Any suggestion on this? My apology for such a question. -- thanks ashish Blog: http://www.ashishpaliwal.com/blog My Photo Galleries: http://www.pbase.com/ashishpaliwal
Re: [Discuss] Is it ok to share other information(not related to project) with community?
2009/4/20 Ashish paliwalash...@gmail.com: I wonder if this offer would have any sense for us. It might be 'a special offer' we're not eligible for. David, for open source these are free. But as part of the community we use JIRA/Confluence. Some of us here may be interested in using them for ourselves. Oh sure, I had understood you, I meant that we (as individuals) could not get the same offer you received. JIRA/Confluence are nice pieces of software but quite pricey. Anyways, the question has a bigger impact, don't want to turn this forum into a marketing place, at the same time we as a community can help each other, in more ways. I guess I am confused :-( Anyone else has an opinion here? - ashish
Re: [jira] Created: (FTPSERVER-289) Implement locking mechanism for files.
Hello Sai, Actually they don't, if you have access to a unix box you can check yourself that it is possible to e.g, move a file which is being currently written. It is windows systems that do prevent concurrent access to files being written - I don't know about other OSes. With FileChannel lock() or tryLock() you can enforce the OS to lock files, but still we probably cannot depend on the user using a 'real filesystem'. For example, we cannot use File.createTempFile() in STOU because the user could be persisting to a database, to a VFS filesystem, to HDFS ... Still, my question here is: Should we provide an abstraction for file locking or allow the filesystem implementation to deal with it internally? 2009/4/16 Sai Pullabhotla sai.pullabho...@jmethods.com: I believe all operating systems handle the file locking on files to prevent concurrent writing. So, if more than one users/sessions try to write to the same file, who ever opens the file first for writing would win and the rest would fail. So not sure if we need to implement what you have mentioned. Thanks. Sai Pullabhotla Phone: (402) 408-5753 Fax: (402) 408-6861 www.jMethods.com On Mon, Apr 13, 2009 at 3:52 AM, David Latorre (JIRA) j...@apache.orgwrote: 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] 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.
[FtpServer] Project based on Apache Mina FtpServer
I came across this project which implements Apache FTPServer on top of HDFS (hadoop distributed file system) : https://sites.google.com/a/iponweb.net/hadoop/Home/hdfs-over-ftp Was it known to you? I've quickly looked over it and the FileSystem over HDFS implementation could be a nice reference for our potential users interested in using Hadoop.
[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.apache.mina.filter.codec.textline.TextLineDecoder.decodeAuto(TextLineDecoder.java:207
[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-tabpanelfocusedCommentId=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.
Re: [jira] Updated: (FTPSERVER-284) Service fails to start
Hello Eyal, I followed the following steps: 1) Downloaded the latest snapshot of FtpServer from SVN. 2) Run mvn install from the base directory (Actually, I used -Dmaven.test.skip=true so I could install this quickly) 3) Unzipped the resulting archive to c:/ftpserver1.0.0) 4) C:\ftpserver-1.0.0 bin\service.bat install ftpd res\conf\ftpd-typical.xml 5) net start ftpd The service is running for me and I'm able to connect to port 21 using anonymous login. Can you include the log file in res/log for any insights? 2009/4/2 Eyal Safran (JIRA) j...@apache.org: [ https://issues.apache.org/jira/browse/FTPSERVER-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eyal Safran updated FTPSERVER-284: -- Description: 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:\apachebin\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. was: 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. Added a description how I set up the FTP Server Service fails to start -- Key: FTPSERVER-284 URL:
[jira] Commented: (FTPSERVER-284) Service fails to start
[ https://issues.apache.org/jira/browse/FTPSERVER-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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:\apachebin\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-tabpanelfocusedCommentId=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:\apachebin\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.
Re: Sai Pullabhotla is a new committer
Welcome Sai! Enjoy your stay 2009/3/31 Maarten Bosteels mbosteels@gmail.com: Welcome Sai ! Maarten On Mon, Mar 30, 2009 at 9:56 AM, Julien Vermillard jvermill...@archean.fr wrote: Le Sun, 29 Mar 2009 20:29:06 +0200, Niklas Gustavsson nik...@protocol7.com a écrit : Hi I'm very glad to announce that the MINA PMC has voted in Sai Pullabhotla as a new MINA committer based on his contributions on the FtpServer subproject. Welcome Sai, hope you'll have fun around here! :-) /niklas Warm Welcome Sai ! Julien
Re: Virtual directory
Hello Reza, As Niklas says, some people have already done that. If this was enough to fit your needs, you can take a look at http://vfs-utils.sourceforge.net/ftpserver/index.html http://vfs-utils.sourceforge.net/ftpserver/index.html which should allow you to use any commons VFS 'provider' for a filesystem 2009/3/22 Niklas Gustavsson nik...@protocol7.com On Fri, Mar 20, 2009 at 12:11 PM, Reza Safari r.saf...@lukkien.com wrote: Is it possible to create my own virtual directory with apache ftp server? I don't have a file system or anything and I want to create my own directory based on some logic, so that the client connected to my server will see a virtual directory instead of a real file system. Yes, this made possible since we have a pluggable file system. As long as you can write an implementation for our file system interfaces, your should be fine. There are several people who have already done something similar, so they might be able to give you further advice if you have more questions. /niklas
Re: Virtual directory
2009/3/23 Ashish paliwalash...@gmail.com David, Added the VFS Bridge project as part of related projects on wiki. was supposed to do it earlier:-( - ashish Yeah I couldn't find it so I had to google for it. Thanks a lot Ashish! I would have added it myself but I can't edit the wiki pages. On Mon, Mar 23, 2009 at 1:44 PM, David Latorre dvl...@gmail.com wrote: Hello Reza, As Niklas says, some people have already done that. If this was enough to fit your needs, you can take a look at http://vfs-utils.sourceforge.net/ftpserver/index.html http://vfs-utils.sourceforge.net/ftpserver/index.html which should allow you to use any commons VFS 'provider' for a filesystem 2009/3/22 Niklas Gustavsson nik...@protocol7.com On Fri, Mar 20, 2009 at 12:11 PM, Reza Safari r.saf...@lukkien.com wrote: Is it possible to create my own virtual directory with apache ftp server? I don't have a file system or anything and I want to create my own directory based on some logic, so that the client connected to my server will see a virtual directory instead of a real file system. Yes, this made possible since we have a pluggable file system. As long as you can write an implementation for our file system interfaces, your should be fine. There are several people who have already done something similar, so they might be able to give you further advice if you have more questions. /niklas -- thanks ashish Blog: http://www.ashishpaliwal.com/blog My Photo Galleries: http://www.pbase.com/ashishpaliwal
Re: [FtpServer] Suspend problem on OSX (was Re: [VOTE] Releasing FtpServer 1.0.0)
2009/3/6 Emmanuel Lecharny elecha...@apache.org
Sai Pullabhotla wrote:
That's what I was expecting. So, if the issue is about RMDIR on the
current
working directory, we should be able to match up the canonical paths and
if
they are same (the directory that was requested for deletion and the
current
working directory), send an error back. Does that sound correct?
:)
Ok, I have changed the RMDIR impl, and now, all the tests are passing.
Following Sai's suggestion, here is what I have :
instead of :
if(file.equals(cwd)) { blah
I now have :
File cwdFile = ((NativeFtpFile)cwd).getPhysicalFile();
File currentFile = ((NativeFtpFile)file).getPhysicalFile();
if (cwdFile.getCanonicalPath().equals(currentFile.getCanonicalPath())) {
blah
and it works on mac.
Could someone do the test on W$ and Linux ?
After changing NativeFtpFile equals to the followingcode :
@Override
public boolean equals(Object obj) {
try{
if(obj != null obj instanceof NativeFtpFile) {
return this.file.getCanonicalPath().equals( ((NativeFtpFile)
obj).file.getCanonicalPath() ) ;
}
}catch(IOException e){}
return false;
}
All the tests are passing under Windows (Vista) with Jre 1.6.0_7 and Jre
1.5.0_15
Thanks for the heads up, Sai !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [FtpServer] Suspend problem on OSX (was Re: [VOTE] Releasing FtpServer 1.0.0)
2009/3/6 Emmanuel Lecharny elecha...@apache.org Niklas Gustavsson wrote: On Fri, Mar 6, 2009 at 11:57 AM, Emmanuel Lecharny elecha...@apache.org wrote: Just a small remark : it would be _very_ cool if you can extend the NativeFtpFile interface with a getFile() method, because having to cast the object to get the so called PhysicalFile is a bit a PITA, IMHO :) Not sure I understand, NativeFtpFile is not an interface but an implementation of the FtpFile interface. And you should pretty much never need to get the underlying java.io.File object unless you really know you're working with the native file system (FtpServer never makes that assumption). And, since there are file system implementations for, for example JDBC, there might not even be a file or even a reasonable object we could return, at least not a java.io.File. Never mind. David's solution is way better. Yesturday, it was late, and it took me a bit of time to find the way to grab the File object, and I found the solution I proposed kind of dirty, to say the least. Doing the job in NativeFtpFile.equals() method is way cleaner. Actually niklas had already commited the change himself when I sent the email, the only difference being that he is not swallowing the Exception as my quick code - I sent the whole code just to remark that I didn't know what to do with that exception. Still I have some concerns about the getCanonicalFile/getCanonicalPath methods because of that IOException. My thinking is that Sun is not using getCanonical... in the File equals() method because it is not safe to rely on it, otherwise, why would they provide a broken implementation of FIle.equals()? Do you know when it's likely that getCanonical* fails? Should we try a workaround in that case? If you think our code is ok as is, that's much better! /niklas -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
[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 ListFtpFile listFiles(); The used generic for the return type prevents users from returning lists with their own type (ie: ListMyFtpFile). A change to: public abstract List? extends FtpFile 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 ListFtpFile listFiles(); The used generic for the return type prevents users from returning lists with their own type (ie: ListMyFtpFile). A change to: public abstract List? extends FtpFile 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.
Re: [VOTE] Releasing FtpServer 1.0.0
+1, Release FtpServer 1.0.0 2009/2/21 Niklas Gustavsson nik...@protocol7.com Hey, this is the vote for the big one dot oh. After our two release candidates, we have fixed two minor bugs and I think we're now ready to go. After 1.0.0, we will start working on patch releases on the 1.0 branch as well as new features for 1.1. You can find the binaries and Maven artifacts here: http://people.apache.org/~ngn/ftpserver/1.0.0/http://people.apache.org/%7Engn/ftpserver/1.0.0/ These files was built from the following code: https://svn.apache.org/repos/asf/mina/ftpserver/branches/1.0.0 Should be release the big guy? [ ]: +1, Release FtpServer 1.0.0 [ ]: 0, Abstain [ ]: -1, Don't release FtpServer 1.0.0 /niklas
Re: [FtpServer] Suspend problem on OSX (was Re: [VOTE] Releasing FtpServer 1.0.0)
2009/2/23 Niklas Gustavsson nik...@protocol7.com Moving this to it's own thread. On Mon, Feb 23, 2009 at 11:08 AM, Guillaume Nodet gno...@gmail.com wrote: FWIW, the test is hanging at the following point: Looks another case of TCP/IP stacks behaving differently on different platforms. Would you be able to see what state the server socket is in when this happens (it runs on a random port so you have to look for the process)? The timeout on the socket is set to 0, so I suspect it will just wait forever ... Well, at least longer then anyone cares to wait around. I'll set a shorter timeout for it. Since neither Niklas nor me have a Mac box handy, can you check this again setting the timeout to a feasible number?
Re: [jira] Commented: (FTPSERVER-271) Embedding FtpServer in RC2 nearly impossible
Hello Claus, Thanks for the report as the changes in the initialization and configuration of FtpServer may be not obvious for previous users. Just to avoid confusion, in Niklas example he uses default as the listener name because that is the name of the default listener on port 21, since the listeners are stored in a Hashmap, the previous default listener will be replaced with your new one ... I mean, if you changed the listener name to something more significative you'd have two listeners up! The solution is to use setListeners(). Keep the good work with Camel (a great product!) 2009/2/3 Claus Ibsen (JIRA) j...@apache.org [ https://issues.apache.org/jira/browse/FTPSERVER-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12669875#action_12669875] Claus Ibsen commented on FTPSERVER-271: --- Thanks Niklas I was a bit frustrated that setting the port wasn't obvious how to do it. Didn't spot the listener factory, and got stuck by the protected setPort on the NioListtener. Thanks for the clarification. We can now upgrade to the RC2 in Camel. Thanks again for the prompt answer. /Claus Embedding FtpServer in RC2 nearly impossible Key: FTPSERVER-271 URL: https://issues.apache.org/jira/browse/FTPSERVER-271 Project: FtpServer Issue Type: Bug Affects Versions: 1.0.0-RC2 Reporter: Claus Ibsen Priority: Critical Hi I might be a bit dissapointed now that when the upgrade from M3 to RC3 with an embedded FtpServer is very complicated as you have changed the API too much. Its hard to set the FTP port number that is a very reasonable configuration to do. This was baiscally how you could do it in M3 but now you have to fight with a NioListener and no way a public setPort method exsists. http://mina.apache.org/ftpserver/embedding-ftpserver.html Could you please reconsider the RC2 to ease the embedding of FtpServer. Its very cool for unit testing other frameworks. Claus Ibsen, a committer on the Apache Camel project http://davsclaus.blogspot.com/ -- 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: 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] 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: 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] 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-tabpanelfocusedCommentId=12665415#action_12665415
]
David Latorre commented on FTPSERVER-267:
-
The documented query string for the authentication statement is this one:
authenticateSELECT userpassword from FTP_USER WHERE
userid='{userid}'/authenticate
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
authenticateSELECT userid from FTP_USER WHERE userid='{userid}' AND
userpassword='{userpassword}'/authenticate
Per this one:
authenticateSELECT userid, userpassword from FTP_USER WHERE
userid='{userid}' AND userpassword='{userpassword}'/authenticate
2- Modify DbUserManager.authenticate from:
HashMapString, Object map = new HashMapString, Object();
map.put(ATTR_LOGIN, escapeString(user));
To this one:
HashMapString, Object map = new HashMapString, Object();
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] 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
authenticateSELECT userid from FTP_USER WHERE userid='{userid}' AND
userpassword='{userpassword}'/authenticate
Per this one:
authenticateSELECT userid, userpassword from FTP_USER WHERE
userid='{userid}' AND userpassword='{userpassword}'/authenticate
2- Modify DbUserManager.authenticate from:
HashMapString, Object map = new HashMapString, Object();
map.put(ATTR_LOGIN, escapeString(user));
To this one:
HashMapString, Object map = new HashMapString, Object();
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] 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-tabpanelfocusedCommentId=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
authenticateSELECT userid from FTP_USER WHERE userid='{userid}' AND
userpassword='{userpassword}'/authenticate
Per this one:
authenticateSELECT userid, userpassword from FTP_USER WHERE
userid='{userid}' AND userpassword='{userpassword}'/authenticate
2- Modify DbUserManager.authenticate from:
HashMapString, Object map = new HashMapString, Object();
map.put(ATTR_LOGIN, escapeString(user));
To this one:
HashMapString, Object map = new HashMapString, Object();
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-tabpanelfocusedCommentId=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.
Re: [FTPServer] IOException under high load - FTPSERVER-260
2009/1/12 Niklas Gustavsson nik...@protocol7.com On Mon, Jan 12, 2009 at 6:32 PM, David Latorre dvl...@gmail.com wrote: Johh Hearn reported this issue with FTPServer https://issues.apache.org/jira/browse/FTPSERVER-260 where under not-that-high loads connections get closed and an Exception is thrown: I've failed to reproduce anything similar on Linux (I don't have a Windows box handy). Also, I failed to pretty much use JMeter at all, would it be possible to create a JUnit test case for this problem? The JMeter code seems to be fairly brutal (not logging out, seems to be opening multiple FileOutputStreams for the same local file) so this might be specific to JMeter (not that we shouldn't handle that, but it would be good to narrow it down a bit). Looking at what the net says about the exception (http://www.sockets.com/err_lst1.htm look for WSAECONNABORTED), it seems to happen when the TCP socket times out due to the client (since we get the error in the server) not sending an ACK (if I understand the description correctly). Here's further explaining the error: http://www.chilkatsoft.com/p/p_299.asp Also, what effects to you see on the server when this happens? I'm guessing only the session dies, right? I also failed to reproduce it on Linux and although it seems specific to JMeter as you said ( I tried to reproduce it with a simple java.net.URL or my ftpclient but i wasn't able to), John said it happened to him during normal working. For me, besides the logged exception everything seems to be working nicely. Maybe John can tell us more about this issue. /niklas
[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-tabpanelfocusedCommentId=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.
Re: [VOTE] Releasing FtpServer 1.0.0-RC1
[X]: +1, Release FtpServer 1.0.0-RC1 [ ]: 0, Abstain [ ]: -1, Don't release FtpServer 1.0.0-RC1 2009/1/12 Julien Vermillard jvermill...@archean.fr [X]: +1, Release FtpServer 1.0.0-RC1 [ ]: 0, Abstain [ ]: -1, Don't release MINA 1.0.0-RC1 Julien
[jira] Commented: (FTPSERVER-260) IOException under high load
[ https://issues.apache.org/jira/browse/FTPSERVER-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] 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-tabpanelfocusedCommentId=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
listeners
nio-listener
name=default
port=XXX
implicit-ssl=false
idle-timeout=60
local-address=XXX
ssl
keystore file=res/xxx.jks password=password/
/ssl
data-connection idle-timeout=60
active enabled=false local-address=XXX local-port=20/
passive ports=XXX-XXX address=
external-address=/
/data-connection
blacklist
/blacklist
/nio-listener
/listeners
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] 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.
