[jira] Created: (FTPSERVER-150) CLONE -Provide convenience methods for checking is the control and data sockets are secure
CLONE -Provide convenience methods for checking is the control and data sockets
are secure
--
Key: FTPSERVER-150
URL: https://issues.apache.org/jira/browse/FTPSERVER-150
Project: FtpServer
Issue Type: Improvement
Affects Versions: 1.0-M2
Reporter: David Latorre
Assignee: Niklas Gustavsson
Fix For: 1.0-M3
Checking if the data and control sockets are secure (running over SSL/TLS) from
a Ftplet is quite intricate and depends on knowledge of the internal
implementation in FtpServer. We should make this simple. Suggestion by Jeroen
Cranendonk
I've cobbled together some code which should give an idea of what I'm trying
to achieve, haven't tested it yet though. And I do realize this probably
breaks your design in all kinds of ways :)
Firstly, I've added the following to FtpSessionImpl:
public boolean isDataConnectionSecure() {
return ioSession.getDataConnection().isSecure();
}
public boolean isSecure() {
return
ioSession.getFilterChain().contains(sslSessionFilter);
}
public void write(final Object message) {
ioSession.write(message);
}
And then my Ftplet looks like this (and it probably won't compile unless
it's against the full ftpserver code):
public class MyFtplet extends DefaultFtplet implements Ftplet {
@Override
public FtpletEnum onUploadStart(final FtpSession session, final
FtpRequest request) throws FtpException,
IOException {
return this.onLimitedStart(session, request);
}
private FtpletEnum onLimitedStart(final FtpSession session, final
FtpRequest request) {
if (session.isSecure() session.isDataConnectionSecure())
{
return FtpletEnum.RET_DEFAULT;
}
session.write(new
DefaultFtpReply(FtpReply.REPLY_550_REQUESTED_ACTION_NOT_TAKEN,
Cannot do this before securing the connection.));
return FtpletEnum.RET_SKIP;
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-150) CLONE -Provide convenience methods for checking is the control and data sockets are secure
[
https://issues.apache.org/jira/browse/FTPSERVER-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12620918#action_12620918
]
David Latorre commented on FTPSERVER-150:
-
Hello,
First of all I apologize if cloning the issue is not the appropriate way of
reporting a problem with a closed issue.
The provided method to find if the connection is secure:
public boolean isSecure() {
return ioSession.getFilterChain().contains(sslSessionFilter);
}
is not sufficient as the SSLFilter in implicit-ssl mode is called sslFilter
rather than sslSessionFilter.
Another possible issue regarding the name of the filters is the metod
getClientCertificates() in FTPIoSession.java:
if(getFilterChain().contains(sslFilter)) {
SslFilter sslFilter = (SslFilter) getFilterChain().get(sslFilter);
Here, we only check if implicit SSL mode is set - and I guess we also want to
be able to obtain the client certificate in explicit-ssl mode.
It would probably be a good idea to distinguish between implicit and explicit
mode (although there's no current usage I can see) so we have several options:
-Rename to sslFilter both the session-related and the listener-related
filter.
-Just check for both filters and maybe create support methods to obtain the
actual sslfilter object or the type of ssl-mode.
What do you think?
CLONE -Provide convenience methods for checking is the control and data
sockets are secure
--
Key: FTPSERVER-150
URL: https://issues.apache.org/jira/browse/FTPSERVER-150
Project: FtpServer
Issue Type: Improvement
Affects Versions: 1.0-M2
Reporter: David Latorre
Assignee: Niklas Gustavsson
Fix For: 1.0-M3
Checking if the data and control sockets are secure (running over SSL/TLS)
from a Ftplet is quite intricate and depends on knowledge of the internal
implementation in FtpServer. We should make this simple. Suggestion by Jeroen
Cranendonk
I've cobbled together some code which should give an idea of what I'm trying
to achieve, haven't tested it yet though. And I do realize this probably
breaks your design in all kinds of ways :)
Firstly, I've added the following to FtpSessionImpl:
public boolean isDataConnectionSecure() {
return ioSession.getDataConnection().isSecure();
}
public boolean isSecure() {
return
ioSession.getFilterChain().contains(sslSessionFilter);
}
public void write(final Object message) {
ioSession.write(message);
}
And then my Ftplet looks like this (and it probably won't compile unless
it's against the full ftpserver code):
public class MyFtplet extends DefaultFtplet implements Ftplet {
@Override
public FtpletEnum onUploadStart(final FtpSession session, final
FtpRequest request) throws FtpException,
IOException {
return this.onLimitedStart(session, request);
}
private FtpletEnum onLimitedStart(final FtpSession session, final
FtpRequest request) {
if (session.isSecure() session.isDataConnectionSecure())
{
return FtpletEnum.RET_DEFAULT;
}
session.write(new
DefaultFtpReply(FtpReply.REPLY_550_REQUESTED_ACTION_NOT_TAKEN,
Cannot do this before securing the connection.));
return FtpletEnum.RET_SKIP;
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-152) NativeFileObject.hasDeletePermission() not working as expected.
NativeFileObject.hasDeletePermission() not working as expected.
Key: FTPSERVER-152
URL: https://issues.apache.org/jira/browse/FTPSERVER-152
Project: FtpServer
Issue Type: Bug
Affects Versions: 1.0-M2, 1.0-M3
Reporter: David Latorre
Fix For: 1.0-M2
In the current implementation, hasDeletePermission in NativeFileObject
delegates to hasWritePermission in order to check whether a file can be deleted
or not. But, in most environments, a file can be deleted when it is parent
directory is writable, no matter if the file is writable itself or not. I
attach a fix which attempts to preserve both options: it will check FTPServer's
write permission for the actual file and if its parent directory is writable.
public boolean hasDeletePermission() {
// root cannot be deleted
if (/.equals(fileName)) {
return false;
}
/* Added 12/08/2008: in the case that the permission is not explicitly
denied for this file
* we will check if the parent file has write permission as most
systems consider that a file can
* be deleted when their parent directory is writable.
*/
String fullName=getFullName();
// we check FTPServer's write permission for this file.
if (user.authorize(new WriteRequest(fullName)) == null) {
return false;
}
// In order to mantain consistency, when possible we delete the last
'/' character in the String
int indexOfSlash=fullName.lastIndexOf('/');
String parentFullName;
if (indexOfSlash==0){
parentFullName=/;
}
else{
parentFullName=fullName.substring(0,indexOfSlash);
}
// we check if the parent FileObject is writable.
NativeFileObject parentObject=new
NativeFileObject(parentFullName,file.getAbsoluteFile().getParentFile(),user);
return parentObject.hasWritePermission();
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-162) DbUserManager's createConnection visibility
DbUserManager's createConnection visibility
Key: FTPSERVER-162
URL: https://issues.apache.org/jira/browse/FTPSERVER-162
Project: FtpServer
Issue Type: Improvement
Affects Versions: 1.0-M3
Reporter: David Latorre
Priority: Minor
If we need to extend DbUserManager we find that the method createConnection is
private :
private synchronized Connection createConnection() throws SQLException {
So we have to implement our own method to create a connection and we cannot use
cachedConnection which is also a private member.
My suggestion is that createConnection be made protected so inheriting classes
can use it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-165) FileSystemBeanDefinitionParser tries to set the property create-home instead of createHome.
FileSystemBeanDefinitionParser tries to set the property create-home instead of createHome. - Key: FTPSERVER-165 URL: https://issues.apache.org/jira/browse/FTPSERVER-165 Project: FtpServer Issue Type: Bug Affects Versions: 1.0-M2, 1.0-M3 Reporter: David Latorre Fix For: 1.0-M3, 1.0-M2 Current code is : builder.addPropertyValue(create-home, Boolean .parseBoolean(element.getAttribute(create-home))); but it should be: builder.addPropertyValue(createHome, Boolean .parseBoolean(element.getAttribute(create-home))); Besides, the xml file used in the tests has no create-home property so the bug remained unnoticed in the tests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-165) FileSystemBeanDefinitionParser tries to set the property create-home instead of createHome.
[ https://issues.apache.org/jira/browse/FTPSERVER-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre updated FTPSERVER-165: Priority: Minor (was: Major) FileSystemBeanDefinitionParser tries to set the property create-home instead of createHome. - Key: FTPSERVER-165 URL: https://issues.apache.org/jira/browse/FTPSERVER-165 Project: FtpServer Issue Type: Bug Affects Versions: 1.0-M2, 1.0-M3 Reporter: David Latorre Priority: Minor Fix For: 1.0-M2, 1.0-M3 Attachments: createHomePatch.patch Original Estimate: 0.08h Remaining Estimate: 0.08h Current code is : builder.addPropertyValue(create-home, Boolean .parseBoolean(element.getAttribute(create-home))); but it should be: builder.addPropertyValue(createHome, Boolean .parseBoolean(element.getAttribute(create-home))); Besides, the xml file used in the tests has no create-home property so the bug remained unnoticed in the tests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-165) FileSystemBeanDefinitionParser tries to set the property create-home instead of createHome.
[ https://issues.apache.org/jira/browse/FTPSERVER-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre updated FTPSERVER-165: Attachment: createHomePatch.patch Patch that solves this problem. FileSystemBeanDefinitionParser tries to set the property create-home instead of createHome. - Key: FTPSERVER-165 URL: https://issues.apache.org/jira/browse/FTPSERVER-165 Project: FtpServer Issue Type: Bug Affects Versions: 1.0-M2, 1.0-M3 Reporter: David Latorre Fix For: 1.0-M2, 1.0-M3 Attachments: createHomePatch.patch Original Estimate: 0.08h Remaining Estimate: 0.08h Current code is : builder.addPropertyValue(create-home, Boolean .parseBoolean(element.getAttribute(create-home))); but it should be: builder.addPropertyValue(createHome, Boolean .parseBoolean(element.getAttribute(create-home))); Besides, the xml file used in the tests has no create-home property so the bug remained unnoticed in the tests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-167) Overridable method to plug-in a password encryption mechanism for authentication
Overridable method to plug-in a password encryption mechanism for authentication Key: FTPSERVER-167 URL: https://issues.apache.org/jira/browse/FTPSERVER-167 Project: FtpServer Issue Type: New Feature Components: Core Affects Versions: 1.0-M3 Reporter: David Latorre Priority: Minor Fix For: 1.0-M3 We need to use ftpserver against an existing database of users. The option to write custom SQL sentences works like a charm so our own difficulty is that passwords are encrypted in the database with a custom algorithm. There are a couple of ways to do that already , but it would be nice to have the possibility to provide our own password-processing method to the UserManager (so we don't have to create a custom UserManager). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-176) FileUserManagerConfigTest fails on Windows.
FileUserManagerConfigTest fails on Windows. --- Key: FTPSERVER-176 URL: https://issues.apache.org/jira/browse/FTPSERVER-176 Project: FtpServer Issue Type: Bug Environment: Windows family probably other non-Unix operating systems. Reporter: David Latorre Priority: Trivial FileUserManagerConfigTest is comparing the path to a file with the fixed String /tmp/foo.users so it will fail on Windows systems. Patch provided. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-176) FileUserManagerConfigTest fails on Windows.
[ https://issues.apache.org/jira/browse/FTPSERVER-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre updated FTPSERVER-176: Component/s: Core Description: FileUserManagerConfigTest is comparing the path to a file with the fixed String /tmp/foo.users so it will fail on Windows systems. This is a trivial++ bug but it prevents maven from building the project, something that discourages users - patch provided. was: FileUserManagerConfigTest is comparing the path to a file with the fixed String /tmp/foo.users so it will fail on Windows systems. Patch provided. Affects Version/s: 1.0-M4 FileUserManagerConfigTest fails on Windows. --- Key: FTPSERVER-176 URL: https://issues.apache.org/jira/browse/FTPSERVER-176 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0-M4 Environment: Windows family probably other non-Unix operating systems. Reporter: David Latorre Priority: Trivial Original Estimate: 0.02h Remaining Estimate: 0.02h FileUserManagerConfigTest is comparing the path to a file with the fixed String /tmp/foo.users so it will fail on Windows systems. This is a trivial++ bug but it prevents maven from building the project, something that discourages users - patch provided. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-176) FileUserManagerConfigTest fails on Windows.
[ https://issues.apache.org/jira/browse/FTPSERVER-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre updated FTPSERVER-176: Attachment: FileUserManagerConfigTestPatch.diff We only need to create a File object from the fixed String (/tmp/foo.users) and compare the absolute paths. FileUserManagerConfigTest fails on Windows. --- Key: FTPSERVER-176 URL: https://issues.apache.org/jira/browse/FTPSERVER-176 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0-M4 Environment: Windows family probably other non-Unix operating systems. Reporter: David Latorre Priority: Trivial Attachments: FileUserManagerConfigTestPatch.diff Original Estimate: 0.02h Remaining Estimate: 0.02h FileUserManagerConfigTest is comparing the path to a file with the fixed String /tmp/foo.users so it will fail on Windows systems. This is a trivial++ bug but it prevents maven from building the project, something that discourages users - patch provided. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-181) The UserManager#authenticate() method lacks of documentation
[ https://issues.apache.org/jira/browse/FTPSERVER-181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12633239#action_12633239 ] David Latorre commented on FTPSERVER-181: - You can check the current implementations of UserManager to solve these questions so I don't know if this should be major priority. Anyway, If you provided better documentation Im sure Niklas will be glad to add it. My understanding is that you're only trying to point a deficiency in the documentation and not that you don't know the answers to those questions yourself. Otherwise, feel free to ask - the mailing list is too quiet anyway. The UserManager#authenticate() method lacks of documentation Key: FTPSERVER-181 URL: https://issues.apache.org/jira/browse/FTPSERVER-181 Project: FtpServer Issue Type: Bug Components: Ftplets Affects Versions: 1.0-M4 Reporter: Andrea Francia The UserManager interface documentation should be a form of contract between the implementor and the user of the interface. After reading the documentation the implementor still has these question: - when I should throw a AuthenticationFailedException? - when I should return a null as a result? - if the object receive two subsequent calls withe the same arguments the objects returned should be the same (same reference), only equals, or they can be different? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-183) DBUserManager is not storing the password in the User object
DBUserManager is not storing the password in the User object Key: FTPSERVER-183 URL: https://issues.apache.org/jira/browse/FTPSERVER-183 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0-M4 Reporter: David Latorre Priority: Minor I suppose that as a result of the change in the strategy to encrypt passwords in DBUserManager, getUserByName() -called by the authenticate() method - returns an User object with the password field unset. When trying to use the save method , this line throws a NullPointerException map.put(ATTR_PASSWORD, escapeString(passwordEncryptor.encrypt(user.getPassword(; I'm providing a patch although maybe there's a more elegant solution. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-183) DBUserManager and PropertiesUserManager are not storing the password in the User object after in authenticate()
[ https://issues.apache.org/jira/browse/FTPSERVER-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre updated FTPSERVER-183: Attachment: UserManagers.patch Patch for the NullPointerException issue in DBUserManager - authenticate() will add the unencrypted password to the User object. DBUserManager and PropertiesUserManager are not storing the password in the User object after in authenticate() -- Key: FTPSERVER-183 URL: https://issues.apache.org/jira/browse/FTPSERVER-183 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0-M4 Reporter: David Latorre Priority: Minor Attachments: UserManagers.patch I suppose that as a result of the change in the strategy to encrypt passwords in DBUserManager, getUserByName() -called by the authenticate() method - returns an User object with the password field unset. When trying to use the save method , this line throws a NullPointerException map.put(ATTR_PASSWORD, escapeString(passwordEncryptor.encrypt(user.getPassword(; My reason to use this method is that I call DBUserManager.save() to update the user in the database with last-login information. I'm providing a patch although maybe there's a more elegant solution. The same modification is done in PropertiesUserManager for coherence. Important Note: with my provided path , the user's password should not be included in the WHERE query of updateStatement as there's a chance that for a PasswordEncryptor, the result of passwordEncryptor.encrypt is not the same as the stored password even if matches() returns true. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-183) DBUserManager and PropertiesUserManager are not storing the password in the User object after in authenticate()
[ https://issues.apache.org/jira/browse/FTPSERVER-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre updated FTPSERVER-183: Description: I suppose that as a result of the change in the strategy to encrypt passwords in DBUserManager, getUserByName() -called by the authenticate() method - returns an User object with the password field unset. When trying to use the save method , this line throws a NullPointerException map.put(ATTR_PASSWORD, escapeString(passwordEncryptor.encrypt(user.getPassword(; My reason to use this method is that I call DBUserManager.save() to update the user in the database with last-login information. I'm providing a patch although maybe there's a more elegant solution. The same modification is done in PropertiesUserManager for coherence. Important Note: with my provided path , the user's password should not be included in the WHERE query of updateStatement as there's a chance that for a PasswordEncryptor, the result of passwordEncryptor.encrypt is not the same as the stored password even if matches() returns true. was: I suppose that as a result of the change in the strategy to encrypt passwords in DBUserManager, getUserByName() -called by the authenticate() method - returns an User object with the password field unset. When trying to use the save method , this line throws a NullPointerException map.put(ATTR_PASSWORD, escapeString(passwordEncryptor.encrypt(user.getPassword(; I'm providing a patch although maybe there's a more elegant solution. Summary: DBUserManager and PropertiesUserManager are not storing the password in the User object after in authenticate() (was: DBUserManager is not storing the password in the User object) DBUserManager and PropertiesUserManager are not storing the password in the User object after in authenticate() -- Key: FTPSERVER-183 URL: https://issues.apache.org/jira/browse/FTPSERVER-183 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0-M4 Reporter: David Latorre Priority: Minor Attachments: UserManagers.patch I suppose that as a result of the change in the strategy to encrypt passwords in DBUserManager, getUserByName() -called by the authenticate() method - returns an User object with the password field unset. When trying to use the save method , this line throws a NullPointerException map.put(ATTR_PASSWORD, escapeString(passwordEncryptor.encrypt(user.getPassword(; My reason to use this method is that I call DBUserManager.save() to update the user in the database with last-login information. I'm providing a patch although maybe there's a more elegant solution. The same modification is done in PropertiesUserManager for coherence. Important Note: with my provided path , the user's password should not be included in the WHERE query of updateStatement as there's a chance that for a PasswordEncryptor, the result of passwordEncryptor.encrypt is not the same as the stored password even if matches() returns true. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-184) IODataConnection ASCII mode does not work as expected.
IODataConnection ASCII mode does not work as expected.
--
Key: FTPSERVER-184
URL: https://issues.apache.org/jira/browse/FTPSERVER-184
Project: FtpServer
Issue Type: Improvement
Reporter: David Latorre
New lines in files sent in ASCII mode are transformed into /r/n no matter
what platform the ftp server is running on. But if I'm not wrong, the new EOL
should be equal to line.separator . If ASCII mode is going to be supported,
this ought to be changed.
The code in IODataConnection.transfer()
{
if (isAscii) {
for (int i = 0; i count; ++i) {
byte b = buff[i];
if (b == '\n' !lastWasCR) {
bos.write('\r');
}
if (b == '\r') {
lastWasCR = true;
} else {
lastWasCR = false;
}
bos.write(b);
}
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-183) DBUserManager and PropertiesUserManager are not storing the password in the User object after in authenticate()
[ https://issues.apache.org/jira/browse/FTPSERVER-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12635691#action_12635691 ] David Latorre commented on FTPSERVER-183: - Niklas, Did you notice this issue? Is there any problem with my solution or some other problems you're foreseeing? DBUserManager and PropertiesUserManager are not storing the password in the User object after in authenticate() -- Key: FTPSERVER-183 URL: https://issues.apache.org/jira/browse/FTPSERVER-183 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0-M4 Reporter: David Latorre Priority: Minor Attachments: UserManagers.patch I suppose that as a result of the change in the strategy to encrypt passwords in DBUserManager, getUserByName() -called by the authenticate() method - returns an User object with the password field unset. When trying to use the save method , this line throws a NullPointerException map.put(ATTR_PASSWORD, escapeString(passwordEncryptor.encrypt(user.getPassword(; My reason to use this method is that I call DBUserManager.save() to update the user in the database with last-login information. I'm providing a patch although maybe there's a more elegant solution. The same modification is done in PropertiesUserManager for coherence. Important Note: with my provided path , the user's password should not be included in the WHERE query of updateStatement as there's a chance that for a PasswordEncryptor, the result of passwordEncryptor.encrypt is not the same as the stored password even if matches() returns true. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-185) Methods User#getAuthorities() is not used and should removed from the interface
[
https://issues.apache.org/jira/browse/FTPSERVER-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12635707#action_12635707
]
David Latorre commented on FTPSERVER-185:
-
sorry but I can't see what's your use-case here.
Can you comment on why you need your own User implementation (not extending
BaseUser!) and how you are implementing it so you can respond to
AuthorizationRequests but you don't have a list of Authorities you can return.
Methods User#getAuthorities() is not used and should removed from the
interface
---
Key: FTPSERVER-185
URL: https://issues.apache.org/jira/browse/FTPSERVER-185
Project: FtpServer
Issue Type: Bug
Components: Ftplets
Reporter: Andrea Francia
As far I understand the User interface should specify how the User
implementations should communicates with the ftpserver.
The ftpserver doesn't known directly if a user is should be authorized to
perform a specific action but it delegate this decisione to the User
implementation.
As I can see from the source code the method for determining if a user can
perform a specific action is:
public interface User {
AuthorizationRequest authorize(AuthorizationRequest request);
...
}
So I don't see the purpose of put in the interface these methods:
Authority[] getAuthorities();
Authority[] getAuthorities(Class? extends Authority clazz);
These methods are not used by the ftpserver so they should not go in the
interface.
The interface beetween two entities should be keep simple as possible.
The getAutorirhies() methods are used only by the specific implementation of
User named BaseUser, another implementation of User should be free to choose
another method for handling permissions.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-196) Add an example of FTPserver deployed to an application server.
[ https://issues.apache.org/jira/browse/FTPSERVER-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre updated FTPSERVER-196: Attachment: ftpserver_in_a_War_Application.zip Netbeans sample project on how to deploy FtpServer to an application server. It is easy enough to create an Eclipse project with these files (you just copy the contents of 'src/java' directory into Eclipse's source root and web.xml to WEB-INF/web.xml. Although I tested it with Glassfish, it should work on most application servers or Servlet containers. Actually, it seems that a bug on Glassfish 2 (according to MINA guys) could prevent FtpServer from running on Windows machines. But it is working perfectly on our linux servers. src/java/ftpd-typical.xml should be edited to point to the appropiate keystore and user.properties files ( in resources/ users.properties there's an example of a user.properties files included in the source of Ftpserver core). Add an example of FTPserver deployed to an application server. -- Key: FTPSERVER-196 URL: https://issues.apache.org/jira/browse/FTPSERVER-196 Project: FtpServer Issue Type: Improvement Components: Server Reporter: David Latorre Attachments: ftpserver_in_a_War_Application.zip An example should be added where FtpServer is deployed to an application server. Easiest way I can see: - Deploy a web application containing Ftpserver Jars in WEB-INF/lib - Configure a Listener in this application which will instantiate FtpServer and call the start() or stop() methods as adequate. An example is provided! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-196) Add an example of FTPserver deployed to an application server.
Add an example of FTPserver deployed to an application server. -- Key: FTPSERVER-196 URL: https://issues.apache.org/jira/browse/FTPSERVER-196 Project: FtpServer Issue Type: Improvement Components: Server Reporter: David Latorre An example should be added where FtpServer is deployed to an application server. Easiest way I can see: - Deploy a web application containing Ftpserver Jars in WEB-INF/lib - Configure a Listener in this application which will instantiate FtpServer and call the start() or stop() methods as adequate. An example is provided! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-197) start() and stop() methods in FtpServer class can fail to unbind ports.
[ https://issues.apache.org/jira/browse/FTPSERVER-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre updated FTPSERVER-197: Affects Version/s: 1.0-M1 1.0-M2 1.0-M3 start() and stop() methods in FtpServer class can fail to unbind ports. Key: FTPSERVER-197 URL: https://issues.apache.org/jira/browse/FTPSERVER-197 Project: FtpServer Issue Type: Bug Affects Versions: 1.0-M1, 1.0-M2, 1.0-M3 Reporter: David Latorre *start() method in FtpServer class tries to start() all the listeners one by one and it sets started=true if all of them succeeded. If one of the listeners throws an exception when starting but some others succeded , it will not close the open listeners. Calling stop() won't have any effect in this case as 'started' is false. *stop() method in FtpServer class returns normally when e.g., there are open connections to the FtpServer but the server is not really stopped. Calling stop() again later won't have any effect as 'started' is false. I'm quite concerned about the fact that calling stop() won't stop the server since this means that when I undeploy my webapplication the port is still open and I need to restart the whole application server in order to have this port available (and prevent memory leaks!, I guess). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-136) incorrent IP used in opening data channel
[ https://issues.apache.org/jira/browse/FTPSERVER-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12640896#action_12640896 ] David Latorre commented on FTPSERVER-136: - So if I understand correctly, Amichal is providing a hostname (something like my-server.dyndns.org) as the external-ip-address in the passive data connection configuration. Is that right? Then, Amichal problem is that even if he's using a hostname which should be resolved through a DNS request, this name always point to the same address. This is because of the caching behaviour of InetAddress. From JavaDocs: InetAddress Caching The InetAddress class has a cache to store successful as well as unsuccessful host name resolutions. The positive caching is there to guard against DNS spoofing attacks; while the negative caching is used to improve performance. By default, the result of positive host name resolutions are cached forever, because there is no general rule to decide when it is safe to remove cache entries. Thus, we should set the security property which defines how long IP address will be cached: networkaddress.cache.ttl (default: -1) Indicates the caching policy for successful name lookups from the name service. The value is specified as as integer to indicate the number of seconds to cache the successful lookup. I find this could be a bit of a trouble because, most probably, Application Servers set themselves the property. And of course if a security manager is on we might not be able to change this setting. What do you think Niklas? Actually, that explanation about spoofing prevention is kinda laughable and I hope this cache forever default is dropped in the jdk! incorrent IP used in opening data channel - Key: FTPSERVER-136 URL: https://issues.apache.org/jira/browse/FTPSERVER-136 Project: FtpServer Issue Type: Bug Environment: Windows XP Reporter: Amichai Rothman Assignee: Niklas Gustavsson Priority: Minor Fix For: 1.0-M4 The IP used in opening the data channel (DATA command) appears to be determined when the ftp server starts, and never updated again. On systems where the IP address might change (such as any dynamic dns host) this causes all data connections to fail, and requires a full restart of the service whenever the IP address changes (which makes the availability of the ftp server unreliable for practical use). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-136) incorrent IP used in opening data channel
[ https://issues.apache.org/jira/browse/FTPSERVER-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12640897#action_12640897 ] David Latorre commented on FTPSERVER-136: - Actually this behaviour I mentioned was changed in Java SE 6 (when there is no Security Manager) but my explanation to the problem was incorrect (although the problem I pointed out would also affect if we fixed this). Now, this is correct (I think) We are building the InetAddress object representing the External Ip Address (when explicitly stated) inside the ListenerBeanDefinitionParser so, as Amichal said, the IP address is never looked up again (InetAddress will lookup the hostname if we didn't provide one when we created the object but won't even know that we didn't provide a numeric ip address so it won't look it up again). The easiest solution I can see is to store the address information in a String fiend and have a getter which will return an InetAddress or retrieve it as a String and build the object when appropriate (Not a problem since we also need to retrieve the local ip if we didn't configure the field in the xml). incorrent IP used in opening data channel - Key: FTPSERVER-136 URL: https://issues.apache.org/jira/browse/FTPSERVER-136 Project: FtpServer Issue Type: Bug Environment: Windows XP Reporter: Amichai Rothman Assignee: Niklas Gustavsson Priority: Minor Fix For: 1.0-M4 The IP used in opening the data channel (DATA command) appears to be determined when the ftp server starts, and never updated again. On systems where the IP address might change (such as any dynamic dns host) this causes all data connections to fail, and requires a full restart of the service whenever the IP address changes (which makes the availability of the ftp server unreliable for practical use). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-215) Secured data channel in active mode would require the server to have a public certificate for every client.
Secured data channel in active mode would require the server to have a public certificate for every client. --- Key: FTPSERVER-215 URL: https://issues.apache.org/jira/browse/FTPSERVER-215 Project: FtpServer Issue Type: Improvement Components: Core Affects Versions: 1.0-M3, 1.0-M2, 1.0-M1, 1.0-M4 Reporter: David Latorre Fix For: 1.0-M4 In active mode , the FtpServer itself will try to open a connection to a client-reported host and port. In this case, if we were using a SSL connection, the server opens a connection to the client so it will receive the client's public certificate and will try and check it against its TrustStore. To my mind, when we are not checking the client certificate we shouldn't check it in Active data connections either. So we should provide our own TrustManager for this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-184) IODataConnection ASCII mode does not work as expected.
[
https://issues.apache.org/jira/browse/FTPSERVER-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12645656#action_12645656
]
David Latorre commented on FTPSERVER-184:
-
Hello,
Sure you are right here, I didn't make myself clear enough Im sorry.
As you (and RFC959) say, when we are sending the file we should transform to
NVT-ASCII but not when we are receiving the file. In this second case, i think
that the expected behaviour is that the text message be written to a file with
the default line separator for the platform.
The sender converts the data from an internal character
representation to the standard 8-bit NVT-ASCII
representation (see the Telnet specification). The receiver
will convert the data from the standard form to his own
internal form.
Actually , according to the spec before a RETR ASCII operation is transformed
we should be converting the charset to ASCII , for our machine could be using
EBCDIC to store files and clients are supposed to expect that files are
encoded in NVT-ASCII.
So I don't know ... Any way, this has little priority for me (until someone
using a non-ascii-compatible encoding complains) so we could leave this for the
future. Any way I don't like ASCII mode for it breaks the 'REST' command. My
implementation only supports binary mode.
IODataConnection ASCII mode does not work as expected.
--
Key: FTPSERVER-184
URL: https://issues.apache.org/jira/browse/FTPSERVER-184
Project: FtpServer
Issue Type: Improvement
Components: Core
Affects Versions: 1.0-M2, 1.0-M3
Reporter: David Latorre
Assignee: Niklas Gustavsson
Fix For: 1.0-M4
New lines in files sent in ASCII mode are transformed into /r/n no matter
what platform the ftp server is running on. But if I'm not wrong, the new
EOL should be equal to line.separator . If ASCII mode is going to be
supported, this ought to be changed.
The code in IODataConnection.transfer()
{
if (isAscii) {
for (int i = 0; i count; ++i) {
byte b = buff[i];
if (b == '\n' !lastWasCR) {
bos.write('\r');
}
if (b == '\r') {
lastWasCR = true;
} else {
lastWasCR = false;
}
bos.write(b);
}
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-215) Secured data channel in active mode would require the server to have a public certificate for every client.
[ https://issues.apache.org/jira/browse/FTPSERVER-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12645732#action_12645732 ] David Latorre commented on FTPSERVER-215: - Secured data channel in active mode would require the server to have a public certificate for every client. This is not true, it would be verified against the signer, which might very well be a known CA certificate (like Verisign) Sure. But in most common scenarios, people don't buy a Versign certificate just to connect to a HTTPS/FTPS server. So that was the worst-case scenario. Anyway, never mind my post I realized that my problem was with a bug in commons net ftp I am going to report(provide a fix for) now. FTPServer correctly creates the socket with useClientMode=false. So, if clients do not use SSL client mode themselves, that should be their fault. Do you agree? So this issue can be closed. Sorry! Secured data channel in active mode would require the server to have a public certificate for every client. --- Key: FTPSERVER-215 URL: https://issues.apache.org/jira/browse/FTPSERVER-215 Project: FtpServer Issue Type: Improvement Components: Core Affects Versions: 1.0-M1, 1.0-M2, 1.0-M3, 1.0-M4 Reporter: David Latorre Fix For: 1.0-M4 In active mode , the FtpServer itself will try to open a connection to a client-reported host and port. In this case, if we were using a SSL connection, the server opens a connection to the client so it will receive the client's public certificate and will try and check it against its TrustStore. To my mind, when we are not checking the client certificate we shouldn't check it in Active data connections either. So we should provide our own TrustManager for this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-219) The STOR command hangs thread in passive mode
[ https://issues.apache.org/jira/browse/FTPSERVER-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12646531#action_12646531 ] David Latorre commented on FTPSERVER-219: - I don't have the code here but it should be easy - just use setSoTimeout , right ? a patch will be welcome if you have already fixed this! The STOR command hangs thread in passive mode - Key: FTPSERVER-219 URL: https://issues.apache.org/jira/browse/FTPSERVER-219 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0-M3, 1.0-M4 Environment: Debian Linux Jdk 1.6.0_10 Reporter: Mikael Svahn If a client does not disconnect a STOR command correct, for instance due to bad transmission the reader thread might hang. I think there must be a timeout on socket read. - java.net.SocketInputStream.socketRead0(java.io.FileDescriptor, byte[], int, int, int) @bci=0 (Interpreted frame) - java.net.SocketInputStream.read(byte[], int, int) @bci=84, line=129 (Interpreted frame) - java.io.BufferedInputStream.fill() @bci=175, line=218 (Compiled frame) - java.io.BufferedInputStream.read1(byte[], int, int) @bci=44, line=258 (Compiled frame) - java.io.BufferedInputStream.read(byte[], int, int) @bci=49, line=317 (Interpreted frame) - java.io.FilterInputStream.read(byte[]) @bci=5, line=90 (Interpreted frame) - org.apache.ftpserver.impl.IODataConnection.transfer(org.apache.ftpserver.ftplet.FtpSession, boolean, java.io.InputStream, java.io.OutputStream, int) @bci=133, line=236 (Interpreted frame) - org.apache.ftpserver.impl.IODataConnection.transferFromClient(org.apache.ftpserver.ftplet.FtpSession, java.io.OutputStream) @bci=51, line=129 (Interpreted frame) - org.apache.ftpserver.command.impl.STOR.execute(org.apache.ftpserver.impl.FtpIoSession, org.apache.ftpserver.impl.FtpServerContext, org.apache.ftpserver.ftplet.FtpRequest) @bci=344, line=147 (Interpreted frame) - org.apache.ftpserver.impl.DefaultFtpHandler.messageReceived(org.apache.ftpserver.impl.FtpIoSession, org.apache.ftpserver.ftplet.FtpRequest) @bci=160, line=135 (Interpreted frame) - org.apache.ftpserver.listener.nio.FtpHandlerAdapter.messageReceived(org.apache.mina.core.session.IoSession, java.lang.Object) @bci=33, line=62 (Interpreted frame) - org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(org.apache.mina.core.filterchain.IoFilter$NextFilter, org.apache.mina.core.session.IoSession, java.lang.Object) @bci=51, line=752 (Inte -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-219) The STOR command hangs thread in passive mode
[ https://issues.apache.org/jira/browse/FTPSERVER-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12648176#action_12648176 ] David Latorre commented on FTPSERVER-219: - Fixed in #714088. I think you can close this niklas. I was checking if my write permission to the repo was ok; but I forgot about jira permissions. The STOR command hangs thread in passive mode - Key: FTPSERVER-219 URL: https://issues.apache.org/jira/browse/FTPSERVER-219 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0-M3, 1.0-M4 Environment: Debian Linux Jdk 1.6.0_10 Reporter: Mikael Svahn If a client does not disconnect a STOR command correct, for instance due to bad transmission the reader thread might hang. I think there must be a timeout on socket read. - java.net.SocketInputStream.socketRead0(java.io.FileDescriptor, byte[], int, int, int) @bci=0 (Interpreted frame) - java.net.SocketInputStream.read(byte[], int, int) @bci=84, line=129 (Interpreted frame) - java.io.BufferedInputStream.fill() @bci=175, line=218 (Compiled frame) - java.io.BufferedInputStream.read1(byte[], int, int) @bci=44, line=258 (Compiled frame) - java.io.BufferedInputStream.read(byte[], int, int) @bci=49, line=317 (Interpreted frame) - java.io.FilterInputStream.read(byte[]) @bci=5, line=90 (Interpreted frame) - org.apache.ftpserver.impl.IODataConnection.transfer(org.apache.ftpserver.ftplet.FtpSession, boolean, java.io.InputStream, java.io.OutputStream, int) @bci=133, line=236 (Interpreted frame) - org.apache.ftpserver.impl.IODataConnection.transferFromClient(org.apache.ftpserver.ftplet.FtpSession, java.io.OutputStream) @bci=51, line=129 (Interpreted frame) - org.apache.ftpserver.command.impl.STOR.execute(org.apache.ftpserver.impl.FtpIoSession, org.apache.ftpserver.impl.FtpServerContext, org.apache.ftpserver.ftplet.FtpRequest) @bci=344, line=147 (Interpreted frame) - org.apache.ftpserver.impl.DefaultFtpHandler.messageReceived(org.apache.ftpserver.impl.FtpIoSession, org.apache.ftpserver.ftplet.FtpRequest) @bci=160, line=135 (Interpreted frame) - org.apache.ftpserver.listener.nio.FtpHandlerAdapter.messageReceived(org.apache.mina.core.session.IoSession, java.lang.Object) @bci=33, line=62 (Interpreted frame) - org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(org.apache.mina.core.filterchain.IoFilter$NextFilter, org.apache.mina.core.session.IoSession, java.lang.Object) @bci=51, line=752 (Inte -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (FTPSERVER-136) incorrent IP used in opening data channel
[ https://issues.apache.org/jira/browse/FTPSERVER-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre reassigned FTPSERVER-136: --- Assignee: David Latorre (was: Niklas Gustavsson) incorrent IP used in opening data channel - Key: FTPSERVER-136 URL: https://issues.apache.org/jira/browse/FTPSERVER-136 Project: FtpServer Issue Type: Bug Environment: Windows XP Reporter: Amichai Rothman Assignee: David Latorre Priority: Minor Fix For: 1.0-M4 The IP used in opening the data channel (DATA command) appears to be determined when the ftp server starts, and never updated again. On systems where the IP address might change (such as any dynamic dns host) this causes all data connections to fail, and requires a full restart of the service whenever the IP address changes (which makes the availability of the ftp server unreliable for practical use). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-136) incorrent IP used in opening data channel
[ https://issues.apache.org/jira/browse/FTPSERVER-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12648680#action_12648680 ] David Latorre commented on FTPSERVER-136: - Patch applied in 718667. The solution should work but there are a lot of nasty hacks in the code. We should want to unify all the different methods which transform a String into an InetAddress ( we should throw a single Exception then). incorrent IP used in opening data channel - Key: FTPSERVER-136 URL: https://issues.apache.org/jira/browse/FTPSERVER-136 Project: FtpServer Issue Type: Bug Environment: Windows XP Reporter: Amichai Rothman Assignee: David Latorre Priority: Minor Fix For: 1.0-M4 The IP used in opening the data channel (DATA command) appears to be determined when the ftp server starts, and never updated again. On systems where the IP address might change (such as any dynamic dns host) this causes all data connections to fail, and requires a full restart of the service whenever the IP address changes (which makes the availability of the ftp server unreliable for practical use). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FTPSERVER-136) incorrent IP used in opening data channel
[ https://issues.apache.org/jira/browse/FTPSERVER-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre resolved FTPSERVER-136. - Resolution: Fixed incorrent IP used in opening data channel - Key: FTPSERVER-136 URL: https://issues.apache.org/jira/browse/FTPSERVER-136 Project: FtpServer Issue Type: Bug Environment: Windows XP Reporter: Amichai Rothman Assignee: David Latorre Priority: Minor Fix For: 1.0-M4 The IP used in opening the data channel (DATA command) appears to be determined when the ftp server starts, and never updated again. On systems where the IP address might change (such as any dynamic dns host) this causes all data connections to fail, and requires a full restart of the service whenever the IP address changes (which makes the availability of the ftp server unreliable for practical use). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FTPSERVER-136) incorrent IP used in opening data channel
[ https://issues.apache.org/jira/browse/FTPSERVER-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre closed FTPSERVER-136. --- Amichai can you test this? I have to find an automatic and portable way to test this. You can change your ip address (e.g, with ifconfig in Unix) and test if connection still works . But since ipaliasing in my linux box doesn't work and actually changes the ip address rather than adding a new one I cannot automate tests. incorrent IP used in opening data channel - Key: FTPSERVER-136 URL: https://issues.apache.org/jira/browse/FTPSERVER-136 Project: FtpServer Issue Type: Bug Environment: Windows XP Reporter: Amichai Rothman Assignee: David Latorre Priority: Minor Fix For: 1.0-M4 The IP used in opening the data channel (DATA command) appears to be determined when the ftp server starts, and never updated again. On systems where the IP address might change (such as any dynamic dns host) this causes all data connections to fail, and requires a full restart of the service whenever the IP address changes (which makes the availability of the ftp server unreliable for practical use). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-230) MFMT Command reply should include a message
[ https://issues.apache.org/jira/browse/FTPSERVER-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12653054#action_12653054 ] David Latorre commented on FTPSERVER-230: - Although there is no official RFC including MFTM , there's a draft so we might want to follow it for this issue: http://tools.ietf.org/html/draft-somers-ftp-mfxx-04#section-3.1 So the correct response when the command succeded is: mfmt-response = 213 SP Modify= time-val ; SP pathname CRLF MFMT Command reply should include a message --- Key: FTPSERVER-230 URL: https://issues.apache.org/jira/browse/FTPSERVER-230 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0.0-M3 Reporter: Sai Pullabhotla Fix For: 1.0.0-M4 MFMT Command replies with just the code 213. We might want to add a message at least saying requested action was successful. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (FTPSERVER-230) MFMT Command reply should include a message
[ https://issues.apache.org/jira/browse/FTPSERVER-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre reassigned FTPSERVER-230: --- Assignee: David Latorre MFMT Command reply should include a message --- Key: FTPSERVER-230 URL: https://issues.apache.org/jira/browse/FTPSERVER-230 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0.0-M3 Reporter: Sai Pullabhotla Assignee: David Latorre Fix For: 1.0.0-M4 MFMT Command replies with just the code 213. We might want to add a message at least saying requested action was successful. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (FTPSERVER-229) MFMT Command - Code Enhancement
[ https://issues.apache.org/jira/browse/FTPSERVER-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre reassigned FTPSERVER-229: --- Assignee: David Latorre MFMT Command - Code Enhancement --- Key: FTPSERVER-229 URL: https://issues.apache.org/jira/browse/FTPSERVER-229 Project: FtpServer Issue Type: Improvement Components: Core Affects Versions: 1.0.0-M3 Reporter: Sai Pullabhotla Assignee: David Latorre Fix For: 1.0.0-M4 MFMT Command - in the source code for this command (MFMT.java), the DateFormat and its configuration should be moved to static block for performance and to reduce object creations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FTPSERVER-229) MFMT Command - Code Enhancement
[ https://issues.apache.org/jira/browse/FTPSERVER-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre resolved FTPSERVER-229. - Resolution: Fixed Fix Version/s: (was: 1.0.0-M4) 1.0.0-RC1 Fix will be provided for 1.0.0-RC1. MFMT Command - Code Enhancement --- Key: FTPSERVER-229 URL: https://issues.apache.org/jira/browse/FTPSERVER-229 Project: FtpServer Issue Type: Improvement Components: Core Affects Versions: 1.0.0-M3 Reporter: Sai Pullabhotla Assignee: David Latorre Fix For: 1.0.0-RC1 MFMT Command - in the source code for this command (MFMT.java), the DateFormat and its configuration should be moved to static block for performance and to reduce object creations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FTPSERVER-230) MFMT Command reply should include a message
[ https://issues.apache.org/jira/browse/FTPSERVER-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre resolved FTPSERVER-230. - Resolution: Fixed Fix Version/s: (was: 1.0.0-M4) 1.0.0-RC1 Fix will be provided for 1.0.0-RC1. MFMT Command reply should include a message --- Key: FTPSERVER-230 URL: https://issues.apache.org/jira/browse/FTPSERVER-230 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0.0-M3 Reporter: Sai Pullabhotla Assignee: David Latorre Fix For: 1.0.0-RC1 MFMT Command replies with just the code 213. We might want to add a message at least saying requested action was successful. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FTPSERVER-231) MFMT Commad does not work on file/path names that have one or more white spaces
[ https://issues.apache.org/jira/browse/FTPSERVER-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre resolved FTPSERVER-231. - Resolution: Fixed Fix Version/s: (was: 1.0.0-M4) 1.0.0-RC1 Assignee: David Latorre Fix will be provided for 1.0.0-RC1. MFMT Commad does not work on file/path names that have one or more white spaces --- Key: FTPSERVER-231 URL: https://issues.apache.org/jira/browse/FTPSERVER-231 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0.0-M3 Reporter: Sai Pullabhotla Assignee: David Latorre Fix For: 1.0.0-RC1 MFMT Commad does not work on file/path names that have one or more white spaces. For example if you have a file named my file.txt, running the MFMT command on this file fails. To fix this, the MFMT.java needs to be changes as follows: String[] arguments = argument.split( ); should be changed to String[] arguments = arguments.split( , 2); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FTPSERVER-232) MFMT command always returns a 2XX reply even if the date could not be set
[ https://issues.apache.org/jira/browse/FTPSERVER-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre resolved FTPSERVER-232. - Resolution: Fixed Fix Version/s: (was: 1.0.0-M4) 1.0.0-RC1 Assignee: David Latorre Fix will be provided for 1.0.0-RC1. MFMT command always returns a 2XX reply even if the date could not be set - Key: FTPSERVER-232 URL: https://issues.apache.org/jira/browse/FTPSERVER-232 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0.0-M3 Reporter: Sai Pullabhotla Assignee: David Latorre Fix For: 1.0.0-RC1 MFMT command always returns a 2XX reply even if the date could not be set. MFMT Command should return a Positive Completion Reply if and only if we are sure that the date on the file was modified. In order to fix this, we need to make use of the return value from java.io.File.setLastModified(long). We are not using the returned boolean from this method and assuming that the new date was set. Code needs to be changed in a few places to fix this. The issue can be reproduced by trying to set the date on a file that is in use. I used a .doc file, had it open in MS Word and ran the MFMT command and got the 213 reply, but the date on the file was not changed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FTPSERVER-234) TYPE command with no argument
[ https://issues.apache.org/jira/browse/FTPSERVER-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre resolved FTPSERVER-234. - Resolution: Fixed Fix Version/s: (was: 1.0.0-M4) 1.0.0-RC1 Makes sense.RFC doesn't list the first parameter as optional. Fix will be provided for 1.0.0-RC1. TYPE command with no argument - Key: FTPSERVER-234 URL: https://issues.apache.org/jira/browse/FTPSERVER-234 Project: FtpServer Issue Type: Improvement Components: Core Affects Versions: 1.0.0-M3 Reporter: Sai Pullabhotla Fix For: 1.0.0-RC1 Not sure if TYPE command with no argument should change the type to ASCII. Instead it should reply back with 2xx reply indicating the current type in use. Not sure what the RFC says. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FTPSERVER-227) DELE command should not delete the current working directory or the any parent of current working directory
[ https://issues.apache.org/jira/browse/FTPSERVER-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre closed FTPSERVER-227. --- Resolution: Duplicate According to FTPSERVER-226 DELE shouldn't delete any directories so this issue is already addressed. DELE command should not delete the current working directory or the any parent of current working directory --- Key: FTPSERVER-227 URL: https://issues.apache.org/jira/browse/FTPSERVER-227 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0.0-M3 Reporter: Sai Pullabhotla Fix For: 1.0.0-M4 DELE command should not delete the current working directory or the any parent of current working directory. case 1: Let us say, the current working directory is /wd then DELE . or DELE /wd should result in a 5XX reply. case 2: Let us say the working directory is /wd/subdir, then DELE /wd or DELE .. should also be restricted and a 5xx reply should be sent. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-228) LIST command on a non-existent directory should result in an error
[ https://issues.apache.org/jira/browse/FTPSERVER-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre updated FTPSERVER-228: Fix Version/s: (was: 1.0.0-M4) 1.0.0-RC1 LIST command on a non-existent directory should result in an error -- Key: FTPSERVER-228 URL: https://issues.apache.org/jira/browse/FTPSERVER-228 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0.0-M3 Reporter: Sai Pullabhotla Fix For: 1.0.0-RC1 LIST command on a non-existent directory should result in an error. Instead, we send an empty list back. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-226) DELE command deletes directories
[ https://issues.apache.org/jira/browse/FTPSERVER-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre updated FTPSERVER-226: Fix Version/s: (was: 1.0.0-M4) 1.0.0-RC1 DELE command deletes directories Key: FTPSERVER-226 URL: https://issues.apache.org/jira/browse/FTPSERVER-226 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0.0-M3 Reporter: Sai Pullabhotla Fix For: 1.0.0-RC1 DELE command should NOT delete the object if the argument represents a directory. According to the FTP Standards RMD command should be used for deleting directories. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (FTPSERVER-229) MFMT Command - Code Enhancement
[ https://issues.apache.org/jira/browse/FTPSERVER-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre reopened FTPSERVER-229: - We should see if we want to fix this , accessing DateFormat in a thread-safe way. Sorry for 'resolving' issues too soon (and not committing them!). MFMT Command - Code Enhancement --- Key: FTPSERVER-229 URL: https://issues.apache.org/jira/browse/FTPSERVER-229 Project: FtpServer Issue Type: Improvement Components: Core Affects Versions: 1.0.0-M4 Reporter: Sai Pullabhotla Assignee: David Latorre Fix For: 1.0.0-RC1 MFMT Command - in the source code for this command (MFMT.java), the DateFormat and its configuration should be moved to static block for performance and to reduce object creations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (FTPSERVER-227) RMD command should not delete the current working directory or the any parent of current working directory
[ https://issues.apache.org/jira/browse/FTPSERVER-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre reassigned FTPSERVER-227: --- Assignee: David Latorre RMD command should not delete the current working directory or the any parent of current working directory -- Key: FTPSERVER-227 URL: https://issues.apache.org/jira/browse/FTPSERVER-227 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0.0-M4 Reporter: Sai Pullabhotla Assignee: David Latorre Fix For: 1.0.0-RC1 Attachments: FTPSERVER-227_patch.text RMD command should not delete the current working directory or the any parent of current working directory. case 1: Let us say, the current working directory is /wd then RMD . or RMD /wd should result in a 5XX reply. case 2: Let us say the working directory is /wd/subdir, then RMD /wd or RMD .. should also be restricted and a 5xx reply should be sent. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FTPSERVER-227) RMD command should not delete the current working directory or the any parent of current working directory
[ https://issues.apache.org/jira/browse/FTPSERVER-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre resolved FTPSERVER-227. - Resolution: Fixed Do you agree with this fix? Or should we trasverse the parentFile()s in order to know if we are trying to delete an 'ancestor' of our current working directory? RMD command should not delete the current working directory or the any parent of current working directory -- Key: FTPSERVER-227 URL: https://issues.apache.org/jira/browse/FTPSERVER-227 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0.0-M4 Reporter: Sai Pullabhotla Assignee: David Latorre Fix For: 1.0.0-RC1 Attachments: FTPSERVER-227_patch.text RMD command should not delete the current working directory or the any parent of current working directory. case 1: Let us say, the current working directory is /wd then RMD . or RMD /wd should result in a 5XX reply. case 2: Let us say the working directory is /wd/subdir, then RMD /wd or RMD .. should also be restricted and a 5xx reply should be sent. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-249) DBUserManager doesn't close Connections leading to pool exhaustion.
DBUserManager doesn't close Connections leading to pool exhaustion. --- Key: FTPSERVER-249 URL: https://issues.apache.org/jira/browse/FTPSERVER-249 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0.0-M4 Reporter: David Latorre Assignee: David Latorre Fix For: 1.0.0-RC1 DBUserManager creates a new Connection in every call but never returns the connections to the pool. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] 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] 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-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.
[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.
[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] 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] 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-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] 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.
[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.
[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.
[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] Created: (FTPSERVER-289) Implement locking mechanism for files.
Implement locking mechanism for files. -- Key: FTPSERVER-289 URL: https://issues.apache.org/jira/browse/FTPSERVER-289 Project: FtpServer Issue Type: New Feature Components: Core Affects Versions: 1.0.0 Reporter: David Latorre Fix For: WISHLIST In order to solve FTPSERVER-288 , this is, to prevent the possibility of race conditions in STOU command ( it is possible that non-unique filenames be generated with the current implementation) we would eventually need that there was some file locking mechanism which might be a mechanism to keep track of in-use files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] 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.
[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.
[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] 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] 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] 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.
[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.
[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.
[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.
[jira] Created: (DIRMINA-773) org.apache.mina.filter.firewall.Subnet should consider 0.0.0.0/0 as a subnet that contains 'all the ipv4 addresses'
org.apache.mina.filter.firewall.Subnet should consider 0.0.0.0/0 as a subnet that contains 'all the ipv4 addresses' Key: DIRMINA-773 URL: https://issues.apache.org/jira/browse/DIRMINA-773 Project: MINA Issue Type: Improvement Components: Filter Affects Versions: 2.0.0-RC1 Reporter: David Latorre One of our users when trying to implement a WhilteListFilter found the problem that there is no way to declare a subnet that would comprise any ip address. As discussed in dev-mailing list, a 0.0.0.0/0 subnet should return always true for Subnet.inSubnet( any_ipv4_address) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-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.
[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-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.
[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.
[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-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.
[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
[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
[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)
[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] [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)
