You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Andy Brook (JIRA)" <ji...@apache.org> on 2010/03/31 18:35:27 UTC
[jira] Created: (NET-315) listFiles() locks up under 2.1, but works
under 2.0
listFiles() locks up under 2.1, but works under 2.0
---------------------------------------------------
Key: NET-315
URL: https://issues.apache.org/jira/browse/NET-315
Project: Commons Net
Issue Type: Bug
Affects Versions: 2.1
Environment: Ubuntu x86_64 9.04, Java x86_64 1.6.0_16-b01
Reporter: Andy Brook
I have several servers that I'm spidering with FTPClient, I initially thought there was something wrong with what Im doing, however, dropping the version back to 2.0, and what I'm seeing goes away.
the following 'System Names' exhibit this lockup behaviour:
||System || Works|| Notes ||
|UNIX Type\: L8| (x)| several sites Im talking to respond with this |
|System Name\: null | (x) | I found that on connect its telling me "Windows_NT"|
Ubuntu 6.06 and 9.04 systems work fine.
Attached will be a test-case maven project, just edit the 'blank.properties' in resources, with valid ftp server values. With commons-net-2.1 it locks up, but backing off to 2.0, it works.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (NET-315) listFiles() locks up under 2.1, but works
under 2.0
Posted by "Andy Brook (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andy Brook updated NET-315:
---------------------------
Attachment: commons-net-problem.zip
here is the [test project|^commons-net-problem.zip]
> listFiles() locks up under 2.1, but works under 2.0
> ---------------------------------------------------
>
> Key: NET-315
> URL: https://issues.apache.org/jira/browse/NET-315
> Project: Commons Net
> Issue Type: Bug
> Affects Versions: 2.1
> Environment: Ubuntu x86_64 9.04, Java x86_64 1.6.0_16-b01
> Reporter: Andy Brook
> Attachments: commons-net-problem.zip
>
>
> I have several servers that I'm spidering with FTPClient, I initially thought there was something wrong with what Im doing, however, dropping the version back to 2.0, and what I'm seeing goes away.
> the following 'System Names' exhibit this lockup behaviour:
> ||System || Works|| Notes ||
> |UNIX Type\: L8| (x)| several sites Im talking to respond with this |
> |System Name\: null | (x) | I found that on connect its telling me "Windows_NT"|
> Ubuntu 6.06 and 9.04 systems work fine.
> Attached will be a test-case maven project, just edit the 'blank.properties' in resources, with valid ftp server values. With commons-net-2.1 it locks up, but backing off to 2.0, it works.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (NET-315) listFiles() locks up under 2.1, but
works under 2.0
Posted by "Rory Winston (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12853093#action_12853093 ]
Rory Winston commented on NET-315:
----------------------------------
Andy
Thanks for this, I've figured out the problem. The issue is actually related to another outstanding JIRA ticket which is NET-313. As a workaround for now, you can either:
* Revert to 2.0
* Apply the patch in NET-313 (if you are building from source).
> listFiles() locks up under 2.1, but works under 2.0
> ---------------------------------------------------
>
> Key: NET-315
> URL: https://issues.apache.org/jira/browse/NET-315
> Project: Commons Net
> Issue Type: Bug
> Affects Versions: 2.1
> Environment: Ubuntu x86_64 9.04, Java x86_64 1.6.0_16-b01
> Reporter: Andy Brook
> Attachments: commons-net-problem.zip
>
>
> I have several servers that I'm spidering with FTPClient, I initially thought there was something wrong with what Im doing, however, dropping the version back to 2.0, and what I'm seeing goes away.
> the following 'System Names' exhibit this lockup behaviour:
> ||System || Works|| Notes ||
> |UNIX Type\: L8| (x)| several sites Im talking to respond with this |
> |System Name\: null | (x) | I found that on connect its telling me "Windows_NT"|
> Ubuntu 6.06 and 9.04 systems work fine.
> Attached will be a test-case maven project, just edit the 'blank.properties' in resources, with valid ftp server values. With commons-net-2.1 it locks up, but backing off to 2.0, it works.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (NET-315) listFiles() locks up under
2.1, but works under 2.0
Posted by "Rory Winston (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12853089#action_12853089 ]
Rory Winston edited comment on NET-315 at 4/3/10 7:08 AM:
----------------------------------------------------------
Hi Andy
Thanks for the complete test case, which is very useful. Just a couple of things:
I see that in your tests, you have the following:
{code:java}
if (files.length==0)
{
LOG.info("No files? BROKEN!!!!!!!!!!!!!");
throw new IOException("broken");
}
{code}
But a zero-length array is a valid return value if a directory is empty.
Also, could you by any chance run this in debug mode and break execution when the program locks up? What would be very useful is a stack trace in this situation.
was (Author: rwinston@eircom.net):
Hi Andy
Thanks for the complete test case, which is very useful. Just a couple of things:
I see that in your tests, you have the following:
{source:java}
if (files.length==0)
{
LOG.info("No files? BROKEN!!!!!!!!!!!!!");
throw new IOException("broken");
}
{source}
But a zero-length array is a valid return value if a directory is empty.
Also, could you by any chance run this in debug mode and break execution when the program locks up? What would be very useful is a stack trace in this situation.
> listFiles() locks up under 2.1, but works under 2.0
> ---------------------------------------------------
>
> Key: NET-315
> URL: https://issues.apache.org/jira/browse/NET-315
> Project: Commons Net
> Issue Type: Bug
> Affects Versions: 2.1
> Environment: Ubuntu x86_64 9.04, Java x86_64 1.6.0_16-b01
> Reporter: Andy Brook
> Attachments: commons-net-problem.zip
>
>
> I have several servers that I'm spidering with FTPClient, I initially thought there was something wrong with what Im doing, however, dropping the version back to 2.0, and what I'm seeing goes away.
> the following 'System Names' exhibit this lockup behaviour:
> ||System || Works|| Notes ||
> |UNIX Type\: L8| (x)| several sites Im talking to respond with this |
> |System Name\: null | (x) | I found that on connect its telling me "Windows_NT"|
> Ubuntu 6.06 and 9.04 systems work fine.
> Attached will be a test-case maven project, just edit the 'blank.properties' in resources, with valid ftp server values. With commons-net-2.1 it locks up, but backing off to 2.0, it works.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (NET-315) listFiles() locks up under 2.1, but works
under 2.0
Posted by "Sebb (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sebb updated NET-315:
---------------------
Component/s: FTP
> listFiles() locks up under 2.1, but works under 2.0
> ---------------------------------------------------
>
> Key: NET-315
> URL: https://issues.apache.org/jira/browse/NET-315
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
> Affects Versions: 2.1
> Environment: Ubuntu x86_64 9.04, Java x86_64 1.6.0_16-b01
> Reporter: Andy Brook
> Attachments: commons-net-problem.zip
>
>
> I have several servers that I'm spidering with FTPClient, I initially thought there was something wrong with what Im doing, however, dropping the version back to 2.0, and what I'm seeing goes away.
> the following 'System Names' exhibit this lockup behaviour:
> ||System || Works|| Notes ||
> |UNIX Type\: L8| (x)| several sites Im talking to respond with this |
> |System Name\: null | (x) | I found that on connect its telling me "Windows_NT"|
> Ubuntu 6.06 and 9.04 systems work fine.
> Attached will be a test-case maven project, just edit the 'blank.properties' in resources, with valid ftp server values. With commons-net-2.1 it locks up, but backing off to 2.0, it works.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (NET-315) listFiles() locks up under 2.1, but
works under 2.0
Posted by "Andy Brook (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12854458#action_12854458 ]
Andy Brook commented on NET-315:
--------------------------------
Thanks, 2.0 it is :)
> listFiles() locks up under 2.1, but works under 2.0
> ---------------------------------------------------
>
> Key: NET-315
> URL: https://issues.apache.org/jira/browse/NET-315
> Project: Commons Net
> Issue Type: Bug
> Affects Versions: 2.1
> Environment: Ubuntu x86_64 9.04, Java x86_64 1.6.0_16-b01
> Reporter: Andy Brook
> Attachments: commons-net-problem.zip
>
>
> I have several servers that I'm spidering with FTPClient, I initially thought there was something wrong with what Im doing, however, dropping the version back to 2.0, and what I'm seeing goes away.
> the following 'System Names' exhibit this lockup behaviour:
> ||System || Works|| Notes ||
> |UNIX Type\: L8| (x)| several sites Im talking to respond with this |
> |System Name\: null | (x) | I found that on connect its telling me "Windows_NT"|
> Ubuntu 6.06 and 9.04 systems work fine.
> Attached will be a test-case maven project, just edit the 'blank.properties' in resources, with valid ftp server values. With commons-net-2.1 it locks up, but backing off to 2.0, it works.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (NET-315) listFiles() locks up under 2.1, but
works under 2.0
Posted by "Rory Winston (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12853089#action_12853089 ]
Rory Winston commented on NET-315:
----------------------------------
Hi Andy
Thanks for the complete test case, which is very useful. Just a couple of things:
I see that in your tests, you have the following:
{source:java}
if (files.length==0)
{
LOG.info("No files? BROKEN!!!!!!!!!!!!!");
throw new IOException("broken");
}
{source}
But a zero-length array is a valid return value if a directory is empty.
Also, could you by any chance run this in debug mode and break execution when the program locks up? What would be very useful is a stack trace in this situation.
> listFiles() locks up under 2.1, but works under 2.0
> ---------------------------------------------------
>
> Key: NET-315
> URL: https://issues.apache.org/jira/browse/NET-315
> Project: Commons Net
> Issue Type: Bug
> Affects Versions: 2.1
> Environment: Ubuntu x86_64 9.04, Java x86_64 1.6.0_16-b01
> Reporter: Andy Brook
> Attachments: commons-net-problem.zip
>
>
> I have several servers that I'm spidering with FTPClient, I initially thought there was something wrong with what Im doing, however, dropping the version back to 2.0, and what I'm seeing goes away.
> the following 'System Names' exhibit this lockup behaviour:
> ||System || Works|| Notes ||
> |UNIX Type\: L8| (x)| several sites Im talking to respond with this |
> |System Name\: null | (x) | I found that on connect its telling me "Windows_NT"|
> Ubuntu 6.06 and 9.04 systems work fine.
> Attached will be a test-case maven project, just edit the 'blank.properties' in resources, with valid ftp server values. With commons-net-2.1 it locks up, but backing off to 2.0, it works.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.