ASF JIRA

[NET-98] SMTP won't work under non-ASCII platforms

Wed, 17 May 2006 19:48:54 -0700 (PDT)

The SMTP code doesn't work on EBCDIC platforms (like IBM os/390) because it
sends the commands in the default platform encoding instead of forcing it to be
ASCII.

I've tested it with an application running on OS/390 trying to do SMTP with a
Domino server also running on OS/390 and it doesn't work because the server
expects ASCII encoding even if it is running on an EBCDIC platform.

It is specified in the SMTP protocol that the commands/responses must be
encoded in ASCII.

I've made it work locally by changing the calls to open the input/output
streams in the com.oroinc.net.smtp.SMTP.connectAction() method by using the
respective constructors accepting an encoding as the second parameter and by
specifying this encoding to be "Cp850". The code changes still works on a
Win2K platform.

I suspect there might be other platforms and/or other protocols that are
affected.

[NET-27] FTPClient getSystem method call returns null value on VMS system

Wed, 19 Sep 2007 22:31:06 -0700 (PDT)

FTPClient getSystem method call returns null value on VMS systems.

This command is successfully processed by server, and its response was "200 VMS
OpenVMS 7.2 ......".

getSystem method is waiting only for "215" (SYSTEM_NAME) response, but "200" is
an other right response (COMMAND_OK).

[NET-102] [net] FTP: NoSuchMethodError thrown when sending command to disconnected FTP server

Dependency — Wed, 19 Sep 2007 22:31:16 -0700 (PDT)

This bug only happens when running under JDK1.3.x or lower.
(when running under JDK1.4.x or higher, this bug does not happen)
Create and configure an FTP server. Make sure it runs OK.

Create a program and run it under JDK1.3.x or lower:
=== Test Program ===================================
...
...
// Connect to the above FTP server and login
// Check that everything went fine.
...
while (true)
{
try { FTPFile[] files = ftpClient.listFiles("*"); showFiles(files); }
catch (FTPConnectionClosedException fcce) { // Oops.. the FTP server has been disconnected. System.out.println("Disconnected from FTP Server. Ending prog."); break; // while(true) }
Thread.sleep(3000);
}
... // close/disconnect and clean-up.
...
====================================================

Run the above program. The ftpClient.listFiles(...) works OK.
At some point, stop the FTP server.

=== Expected result: ===============================
Program ends normally with message "Disconnected from FTP Server. Ending prog."
====================================================

=== Actual result: =================================
Pogram throws java.lang.NoSuchMethodError.
====================================================

=== Stacktrace: ====================================
java.lang.NoSuchMethodError
at org.apache.commons.net.ftp.FTP.sendCommand(FTP.java:442)
at org.apache.commons.net.ftp.FTP.sendCommand(FTP.java:484)
at org.apache.commons.net.ftp.FTP.sendCommand(FTP.java:533)
at org.apache.commons.net.ftp.FTP.pasv(FTP.java:833)
at org.apache.commons.net.ftp.FTPClient.openDataConnection
(FTPClient.java:493)
at org.apache.commons.net.ftp.FTPClient.initiateListParsing
(FTPClient.java:2356)
at org.apache.commons.net.ftp.FTPClient.initiateListParsing
(FTPClient.java:2330)
at org.apache.commons.net.ftp.FTPClient.listFiles(FTPClient.java:2072)
at org.apache.commons.net.ftp.FTPClient.listFiles(FTPClient.java:2123)
====================================================

=== Probable cause: ================================
The FTP.sendCommand(...) method, on line 442 is as follows:

if (!isConnected() || socket == null || !socket.isConnected())

The 'socket' variable is of type 'java.net.Socket'.
Under JKD1.3, the 'java.net.Socket' class does NOT implement 'isConnected()'.
====================================================

Why this bug is "P1 & critical": If the FTP Server closed the connection (e.g.
due to a time-out), our code catches the FTPConnectionClosedException exception
and tries to reconnect to the server. If this exception is not thrown, but the
NoSuchMethodError is thrown instead, our code fails.

PS: It is hard to find information about which JDK-versions support the
Commons/Net component. This page (http://jakarta.apache.org/commons/net/changes-
report.html#1_3_0), indicates that the component should run correctly at least
under JDK1.3.x.

[NET-60] commons-net 1.2 incompatible with JDK < 1.4

Wed, 19 Sep 2007 22:31:10 -0700 (PDT)

<raghu.changlaveedu@bt.com>
> I got this error when using JDK 1.3.1_09
> version.
>
> java.lang.IllegalAccessError: try to access method
> java.util.Calendar.getTimeInMillis()J from class
> org.apache.commons.net.ftp.parser.NTFTPEntryParser

"Edelson, Justin" <Justin.Edelson@mtvi.com>:
>However, net 1.2 won't compile against anything prior to 1.4 (I'm
>working with 1.3.1) because
>org.apache.commons.net.ftp.parser.NTFTPEntryParser tries to call
>Calendar.getTimeInMillis() on line 132, which prior to 1.4 was a
>protected method.

[NET-44] FTP get actions won't download files

Wed, 19 Sep 2007 22:31:08 -0700 (PDT)

The FTP get action returns success but does not get files.

Environment:
------------
ant 1.6.0 (downloaded December 18th)
Windows 2000 Server
JAVA_HOME=c:\jsdk1.4.1_02
ANT_HOME=c:\ant1.6
ANT_OPTS=-Xmx128m
ClassPath=c:\ant1.6\apache-ant-1.6.0\lib

Steps to reproduce:
-------------------
1. Create an anonymous ftp server on a windows localhost
2. Create the following target (substitute the server and login credentials as
necessary):

3. run the following ant command from the location of your build.xml:
ant downloadftp

Note that the following output appears on std. out:

downloadftp:
[ftp] getting files
[ftp] 0 files retrieved

BUILD SUCCESSFUL
Total Time: 2 seconds

No matter what settings I try the get action does not work.

[NET-216] KeyManager and TrustManager not used for data socket

Sun, 27 Apr 2008 15:06:23 -0700 (PDT)

When setting the KeyManager and TrustManager for FtpsClient, it will not be used for the data connection. In addition, the current code eats an exception and just dumps it to stderr.

[NET-208] TelnetInputStream swallows interruptedexception as IOException

Fri, 16 May 2008 16:19:15 -0700 (PDT)

The TelnetInputStream catches InterruptedException in the read() method (line 342) and throws a new IOException without wrapping the InterruptedException. This means that the fact that the read() method was interrupted can hardly be distinguished from any other IOException.

I use thread interruption as a cancellation mechanism for a thread that uses the TelnetInputStream to read data.

The read method is not allowed to throw InterruptedException, so I propose to fix it by at least wrapping the underlying InterruptedException:

catch (InterruptedException e)

{ throw new IOException("Fatal thread interruption during read.", e); }

[NET-206] Turkish 'i' problem and ParserInitializationException: Unknown parser type: Windows_NT

Fri, 16 May 2008 02:20:43 -0700 (PDT)

When default locale of a JVM is set to tr_TR with the UTF-8 encoding the following error is seen when connecting to windows ftp server:
...
at org.apache.commons.net.ftp.parser.ParserInitializationException: Unknown parser type: Windows_NT
at org.apache.commons.net.ftp.parser.DefaultFTPFileEntryParserFactory.createFileEntryParser(DefaultFTPFileEntryParserFactory.java:118)
at org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2358)
at org.apache.commons.net.ftp.FTPClient.listFiles(FTPClient.java:2141)
at org.apache.commons.net.ftp.FTPClient.listFiles(FTPClient.java:2188)
...

[NET-201] UnixFTPEntryParser does not handle character/block special devices properly

Reference — Sun, 16 Mar 2008 14:46:13 -0700 (PDT)

The following is a valid entry from a FreeBSD system:

crw-r----- 1 root kmem 0, 27 Jan 30 11:42 kmem

This causes a parse error, because the regular expression does not allow for the major and minor device numbers.

[NET-198] FTPTimestampParserImpl#parseTimeStamp() is not fully testable

Blocker — Sun, 9 Mar 2008 15:45:45 -0700 (PDT)

The FTPTimestampParserImpl#parseTimeStamp() method is not fully testable, because it unconditionally creates Calendar items using the current time.

In order to test for leap years and DST, the test code needs to be able to set arbitrary times.

I suggest adding a package-private method that takes an additional Calendar parameter, as follows:

Calendar parseTimestamp(String timestampStr, Calendar now) throws ParseException {
// etc

This would replace the original code; the public interface would delegate to the package-private method:

public Calendar parseTimestamp(String timestampStr) throws ParseException { Calendar now = Calendar.getInstance(); return parseTimestamp(timestampStr, now); }

Patch to follow.

[NET-193] FTP throw NullPointerException when enountering 02-29-2008 (leap year bug)

Duplicate — Sat, 8 Mar 2008 11:50:45 -0800 (PST)

ant FTP task blowing up when parsing directories containing ANY items dated (created/modified) February 29 2008.

There may be a workaround using defaultDateFormatConfig or recentDateFormatConfig - but I didn't find it (actually by messing with some of the ftp attributes my build finally stopped throwing NullPointerExceptions, but refused to list or get any files!! Always came back with 0 files found)

Not sure the date format used by Windows FTP server - One thing I am sure of: tasks that once worked stopped working on Friday - it took all weekend and most of today to figure it out. By updating files and folders, magically ftp task begins working agains and I slowly begin regain my sanity

Here's the exception:
D:\builds\build.xml:23: java.lang.NullPointerException
at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:115)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:357)
at org.apache.tools.ant.Target.performTasks(Target.java:385)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1329)
at org.apache.tools.ant.Project.executeTarget(Project.java:1298)
at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1181)
at org.apache.tools.ant.Main.runBuild(Main.java:698)
at org.apache.tools.ant.Main.startAnt(Main.java:199)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)
Caused by: java.lang.NullPointerException
at org.apache.tools.ant.taskdefs.optional.net.FTP$FTPDirectoryScanner.scandir(FTP.java:374)
at org.apache.tools.ant.taskdefs.optional.net.FTP$FTPDirectoryScanner.accountForIncludedDir(FTP.java:459)
at org.apache.tools.ant.taskdefs.optional.net.FTP$FTPDirectoryScanner.scandir(FTP.java:383)
at org.apache.tools.ant.taskdefs.optional.net.FTP$FTPDirectoryScanner.checkIncludePatterns(FTP.java:270)
at org.apache.tools.ant.taskdefs.optional.net.FTP$FTPDirectoryScanner.scan(FTP.java:233)
at org.apache.tools.ant.taskdefs.optional.net.FTP.transferFiles(FTP.java:1570)
at org.apache.tools.ant.taskdefs.optional.net.FTP.transferFiles(FTP.java:1683)
at org.apache.tools.ant.taskdefs.optional.net.FTP.execute(FTP.java:2373)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105)
... 11 more
— Nested Exception —
java.lang.NullPointerException
at org.apache.tools.ant.taskdefs.optional.net.FTP$FTPDirectoryScanner.scandir(FTP.java:374)
at org.apache.tools.ant.taskdefs.optional.net.FTP$FTPDirectoryScanner.accountForIncludedDir(FTP.java:459)
at org.apache.tools.ant.taskdefs.optional.net.FTP$FTPDirectoryScanner.scandir(FTP.java:383)
at org.apache.tools.ant.taskdefs.optional.net.FTP$FTPDirectoryScanner.checkIncludePatterns(FTP.java:270)
at org.apache.tools.ant.taskdefs.optional.net.FTP$FTPDirectoryScanner.scan(FTP.java:233)
at org.apache.tools.ant.taskdefs.optional.net.FTP.transferFiles(FTP.java:1570)
at org.apache.tools.ant.taskdefs.optional.net.FTP.transferFiles(FTP.java:1683)
at org.apache.tools.ant.taskdefs.optional.net.FTP.execute(FTP.java:2373)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:357)
at org.apache.tools.ant.Target.performTasks(Target.java:385)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1329)
at org.apache.tools.ant.Project.executeTarget(Project.java:1298)
at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1181)
at org.apache.tools.ant.Main.runBuild(Main.java:698)
at org.apache.tools.ant.Main.startAnt(Main.java:199)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)

[NET-188] FTPClient#listFiles returns null element when file's timestamp is "02/29"

Blocker — Thu, 26 Jun 2008 02:57:05 -0700 (PDT)

This issue has same cause as ~~VALIDATOR-221~~.
org.apache.commons.net.ftp.parser.FTPTimestampParserImpl#parseTimestamp throws ParseException with timestampStr = "Feb 29 11:22".

FTP Server status:

[root@localhost test-commonsnet]# pwd
/tmp/test-commonsnet
[root@localhost test-commonsnet]# ls -l
total 0
-rw-r--r--  1 root root 0 Dec 19  2006 aaa.txt
-rw-r--r--  1 root root 0 Feb 29 11:22 bbb.txt

test code:

public void testCommonsNetLeapDay() throws Exception {
    final FTPClient ftp = new FTPClient();
    ftp.connect(host);
    ftp.login(user, password);
    final FTPFile[] listFiles = ftp.listFiles("/tmp/test-commonsnet");
    for (int i = 0; i < listFiles.length; i++) {
        System.out.println("[" + i + "] " + listFiles[i]);
    }
    ftp.disconnect();
}

results bellow.

[0] -rw-r--r--    1 0        0               0 Dec 18  2006 aaa.txt
[1] null

Second element(bbb.txt) should not be null.

[NET-184] FtpClient.listFiles truncates directory name beginning with a number

Tue, 19 Feb 2008 13:30:19 -0800 (PST)

I used FtpClient.listFiles() to get a listing of all files in the current working directory on a remote Windows server. If a remote directory begins with a number followed by a space and more text (e.g., 2008 Rates) the name returned by FTPFile.getName() has the leading number truncated (so '2008 Rates' would be 'Rates'). Examining the value returned by FTPFile.toString() or getRawListing() both show the full file name, but the name returned by getName() is truncated.

If the directory begins with a number and is not followed by a space (e.g., 2008_Rates) the correct name is returned by getName(). If there is a number after the test (like'Rates for 2008') the correct name is returned by getName().

Files do not appear to be affected by this. The getName() function returns the correct name regardless of the position of a number or the white space aorund it.

[NET-182] NPE in DefaultFTPFileEntryParserFactory

Sun, 17 Feb 2008 16:22:37 -0800 (PST)

createFileEntryParser needs to null protect from a null 'key' parameter.

[NET-179] NET-73 "TelnetInputStream._read() hangs" fix is not included in nightly builds.

Tue, 19 Feb 2008 14:35:51 -0800 (PST)

The fix for "TelnetInputStream._read() hangs" was not included in nightly builds.May i know the exact solution for this problem.

[NET-178] Support for unciode character is missing

Thu, 21 Feb 2008 04:03:32 -0800 (PST)

I'm using sendMessageData() method of SMTPClient class to obtain a Writer object. The mails i need to send contain unicode characters. The Writer which sendMessageData() method returns, uses "ISO-8859-1" encoding which does not provide support for all unicode characters. Also the encoding is not configurable i.e. there is no method through which i can set the encoding to something else. This issue has delayed the release of my project. I think this is a very major issue which needs to be addressed as soon as possible. Unicode support should be provided by this API or encoding must be made configurable. Please provide me a workaround for this issue. It's very urgent!

[NET-174] if 150 Here comes directory listing comes before 200, then FTPClient throws exception

Dependants — Tue, 26 Feb 2008 02:48:20 -0800 (PST)

1. On a FTPClient.listNames(dir), if the 150 Here comes the directory listing, comes before 200 Directory Send Ok, then org.apache.commons.net.ftp.FTP throws exception:
Could not parse response code. Server Reply: comes the directory listing.

2. Also there seems to be no way to set verbose off.

May I know how to resolve the above? Please pardon me if I am missing something here.

[NET-171] Improve MVSFTPEntryParser.java

Sun, 17 Feb 2008 16:19:43 -0800 (PST)

Hi there,

the "MVSFTPEntryParser" who parses the output of an FTP LIST of an MVS FTP server, is a sad view... it's totally broken. I developed a custom FTPEntryParser, which I can hook into the FtpClient (thank you for the highly customizable design). I'd like to donate it to COMMONS NET... who can I turn to?

Arno Unkrig

[NET-170] UnixFTPEntryParser does not handle file owner names with spaces

Tue, 19 Feb 2008 14:29:46 -0800 (PST)

The regex in UnixFTPEntryParser does not cope with the situation where the file owner name contains spaces. A patch was previously submitted to fix group names with spaces but a similar bug also affects the owner name. As a result, a call to FTPClient.listFiles() returns a FTPFile[] which does not contain entries for affected files.

[NET-169] Cannot return files with listNames() function

Wed, 12 Mar 2008 14:03:15 -0700 (PDT)

Hi,
I am connecting to an ftp server with my username and password. When I call ftpClient.listNames(); it returns 0 length string array although i am very sure that there are files inside.

I also know that when I changed the ftp server to another one this function works. So I am assuming the server that I connected has a weird ftp server. When I called the function ftpClient.getSystemName() it returns UNKNOWN Type: L8.
If I call ftpClient.listNames I got this exception
org.apache.commons.net.ftp.parser.ParserInitializationException: Unknown parser type: UNKNOWN Type: L8
at org.apache.commons.net.ftp.parser.DefaultFTPFileEntryParserFactory.createFileEntryParser(DefaultFTPFileEntryParserFactory.java:125)
at org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2362)
at org.apache.commons.net.ftp.FTPClient.listFiles(FTPClient.java:2145)
at org.apache.commons.net.ftp.FTPClient.listFiles(FTPClient.java:2192)

I have to get the filenames from the server, so how can I solve the problem.
Thanks for the helps.
Burak Ulutoprak

[NET-161] TFTP TFTPClient.sendFile() just doesen't work

Blocker — Tue, 19 Feb 2008 14:41:57 -0800 (PST)

sendFile() in TFTP sendFile() method does not work. It does not causes an error.
Looks like there is a bug in the communication.
I testet it with a sniffer.
1. write request looks ok
2. aknowlege from server
3. aknowlege from server
4. aknowlege from server
and so on.
I replaced the lib with version 1.1 and it works now.

[NET-157] Get "hidden files" over ftp, using commons-vfs

Sun, 17 Feb 2008 16:09:05 -0800 (PST)

I was trying to show "hidden files" by using commons-vfs, but I found no solution to do this by the way.
So I have patched the FTPClient - Class in commons-net 2.0.
The Default-Constructor sets the "__listHiddenFiles" property to false. I change the property to true.

-----------------------------

"__listHiddenFiles = true;"

-----------------------------

The next necessary change I made, was in the "getListArguments" method:

-----------------------------

protected String getListArguments(String pathname) {
if (getListHiddenFiles() && pathname != null) { StringBuffer sb = new StringBuffer().append("-a ").append(pathname); pathname = sb.toString(); } else if (getListHiddenFiles()) { pathname = "-a "; }
return pathname;
}

-----------------------------

Maybe you can integrate this patch in your next apache.commons.net version?

[NET-155] Integer is too small to hold article number value (NNTPClient __parseNewsgroupListEntry() function)

Wed, 19 Sep 2007 22:31:24 -0700 (PDT)

running the following code:

client.connect("news.icm.edu.pl");
NewsgroupInfo[] grps = client.listNewsgroups();

results MalformedServerReplyException (alt.atheism 2147485259 2147483647 y)

it's because in function NNTPClient.__parseNewsgroupListEntry():

last = tokenizer.nextToken();
first = tokenizer.nextToken();
permission = tokenizer.nextToken();

try

{ lastNum = Integer.parseInt(last); firstNum = Integer.parseInt(first); result._setFirstArticle(firstNum); result._setLastArticle(lastNum); if((firstNum == 0) && (lastNum == 0)) result._setArticleCount(0); else result._setArticleCount(lastNum - firstNum + 1); }

catch (NumberFormatException e)

{ return null; }

lastNum and firstNum are Integer (too small for received values)

[NET-151] [PATCH] Allow user to force passive connections to use connected host in FTPClient

Thu, 15 Feb 2007 14:33:35 -0800 (PST)

Currently, FTPClient always uses the host and port returned to it from the reply to a passive connection request.
Some FTP hosts are set incorrectly or are set behind a NAT so they report the incorrect IP address to use for the connection and the transfer will fail to connect.
This patch allows the user to tell FTPClient to use the connected host instead of the host given from the passive reply.
Doing so will allow successful transfers even when the report FTP server returns an incorrect IP address.

[NET-148] Relaxed condition in __getReply causes other failures.

Dependants — Thu, 21 Feb 2008 15:05:51 -0800 (PST)

In FTP.java's __getReply() method, this do/while loop reads multi-line responses from the server:

{ line = _controlInput.readLine(); ... }

while (!(line.length() >= 4 && line.charAt(3) != '-' &&
Character.isDigit(line.charAt(0))));
// This is too strong a condition because of non-conforming ftp
// servers like ftp.funet.fi which sent 226 as the last line of a
// 426 multi-line reply in response to ls /. We relax the condition to
// test that the line starts with a digit rather than starting with
// the code.
// line.startsWith(code)));
}

Note the comment and the commented-out termination condition. I think the relevant spec is http://www.ietf.org/rfc/rfc0959.txt and the section is "4.2. FTP REPLIES". This is causing problems with the return from the STAT command from Geocities' FTP servers. Here is an example reply.

211- ftp.us.geocities.com FTP server status:
Version wu-2.6.0(48) Tue Jan 2 16:30:15 PST 2007
Connected to 144.212.217.85
Logged in anonymously
TYPE: ASCII, FORM: Nonprint; STRUcture: File; transfer MODE: Stream
No data connection
0 data bytes received in 0 files
0 data bytes transmitted in 0 files
0 data bytes total in 0 files
57 traffic bytes received in 0 transfers
733 traffic bytes transmitted in 0 transfers
834 traffic bytes total in 0 transfers
211 End of status

Note that the line "0 data bytes total in 0 files" starts with a digit, but it isn't a reply code. This prematurely halts reading of lines from the server, and the remaining lines will look like a reply from the next command.

[NET-146] wrong handling of timeouts

Wed, 20 Dec 2006 02:54:17 -0800 (PST)

If you set a timeout on the control connection and then make a data transfer (upload, download) which takes longer than that timeout, the client throws the following exception. It seems like the client tries to read something from the control connection while the data transfer is in progress and then it just throws an exception. It makes the application think that the transfer failed even though it succeeded.

aused by: java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read(BufferedInputStream.java:235)
at java.io.FilterInputStream.read(FilterInputStream.java:66)
at java.io.PushbackInputStream.read(PushbackInputStream.java:120)
at org.apache.commons.net.io.FromNetASCIIInputStream.__read(FromNetASCIIInputStream.java:75)
at org.apache.commons.net.io.FromNetASCIIInputStream.read(FromNetASCIIInputStream.java:170)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read(BufferedInputStream.java:235)
at org.apache.commons.net.telnet.TelnetInputStream.__read(TelnetInputStream.java:114)
at org.apache.commons.net.telnet.TelnetInputStream.run(TelnetInputStream.java:535)
at java.lang.Thread.run(Thread.java:595)

[NET-145] Deadlock in TelnetInputStream

Reference — Wed, 3 Jan 2007 08:16:05 -0800 (PST)

"Sometimes" single threads of our application (each thread transfering data from ftp servers) get locked forever. When monitoring our tool with JConsole, I can see that such a thread usually hangs at org.apache.commons.net.telnet.TelnetInputStream, line 339.

This line contains the statement
__queue.wait();

Unfortunately I haven't found a way to reproduce this issue, it just happens about once a day (while running 24 hours and transfering about 50000 files).

As a quick and dirty workaround: What do you think about replacing this line with something like
long startTime = System.currentTimeMillis();
__queue.wait(60000);
if ((System.currentTimeMillis() - startTime) > 55000) {
throw new InterruptedException("Unknown strange and nasty blocker detected");
}

So at least it would not just block the thread.

[NET-141] Add connection timeout support to SocketClient and/or SocketFactory/DefaultSocketFactory

Wed, 19 Sep 2007 22:31:22 -0700 (PDT)

Hi,

If executing the following code
String hostname = "localhost";
FTPClient client = new FTPClient();
client.setDefaultTimeout(1000);
client.connect(hostname);

against a ftp server that ignores the connection attempt (e.g. is firewalled/malfunctoned), there will be no exception after 1000 ms. The exception will be thrown after a default timeout of three minutes. (Three minutes on a debian/ and a suse machines. Might be different on other platforms).

JavaDoc says:
public void setDefaultTimeout(int timeout)
Set the default timeout in milliseconds to use when opening a socket.

Digging through the code I found, that DefaultSocketFactory which is used be SocketClient does not care about any value set with this method. It creates a new Socket with Socket(hostname, port) and relies on the VMs behaviour.

To get this fixed I set a custom SocketFactory with client.setSocketFactory(socketFactory); that uses a timeout for socket connection.

This bug is also in 1.4.1, but this value is not listed...

Christian

[NET-140] FTPClient listFiles returns incorrect timestamp on freshly uploaded file but corrects itself after about 15 minutes

Reference — Mon, 4 Jun 2007 06:06:15 -0700 (PDT)

This is an odd one:

We upload GPS data each hour to a public site using FTPClient. Every 24 hours we check for files older than 60 days using listFiles and getting the timestamps do decide if we want to delete older files.

When we list the files, the most recently uploaded files have a time stamp exactly one year too old. After about 15 minutes, it seems to correct itself and eventually displays the correct timestamp.

During this time while FTPFile.getTimestamp is giving the incorrect timestamp, browsing the folder with a web browser, a commercial FTP client, or actually checking the file info in a shell shows the correct timestamp (i.e. does not seem to be a problem on the remote site)

commons-net-1.4.1 (as well as commons-net-20060901) exhibits this behavior.

commons-net-1.3.0 works properly

I did a little investigating, and it seems to happen with every file written to the remote directory each hour, and the incorrect timestamp will be returned using listFiles for about 15 minutes... and then it corrects itself.

[NET-139] Trunk fails to build under JDK 1.6

Wed, 19 Sep 2007 22:31:22 -0700 (PDT)

java:compile:
[echo] Compiling to /home/hen/apache/jakarta/commons-proper/net/target/classes
[javac] Compiling 150 source files to /home/hen/apache/jakarta/commons-proper/net/target/classes
javac: target release 1.2 conflicts with default source release 1.5

[NET-73] [net][PATCH] TelnetInputStream.read hangs when socket data ends in a command sequence

Tue, 4 Mar 2008 17:20:23 -0800 (PST)

Background: If one calls TelnetInputStream.read() in single-threaded mode (no
reader thread) and there is no data immediately available, the call blocks on
a socket read. When data starts to arrive, the stream adds all the available
bytes to its internal queue before returning the first one to the caller. To
do this, it calls __read() in a loop for as long as there are bytes available.
The __read() method returns the first byte of "user data" from the socket. If
__read() encounters a Telnet command sequence (IAC, WILL, WONT, DO, DONT,
etc.), it handles the negotiation transparently and then returns the first
byte of user data.

In most cases, this works fine, but a problem arises if a chunk of data from
the remote host ends in a Telnet command sequence. When that happens, the
TelnetInputStream.read() method hangs, even though it may have already
acquired some user data. This is because it calls __read() in a loop as long
as super.available() returns true. But if the remaining data from the socket
consists entirely of Telnet commands, __read() will process those AND THEN
BLOCK waiting for user data.

Just checking super.available() is not sufficient. We should continue the loop
only if there are bytes of USER DATA still available from the socket. Not
doing this can cause the client to wait indefinitely.

[NET-28] [PATCH] [net] patch of FTPS

Wed, 19 Sep 2007 22:31:06 -0700 (PDT)

Hi, All.

I have improved and tested some functions of FTPS.

DO NOT REPLY [COM-2710] - [net] How to implent FTPS
　http://marc.theaimsgroup.com/?t=113763609300003&r=1&w=2

I attach a patch (src.zip).

Changes:

add the implicit mode
add the CCC command handling
improve a behavior of the PROT command. (C and P)

Sources:
FTPSClient.java [modified]
FTPSCommand.java [new]
FTPSReply.java [new]

Best Regards.

[NET-99] [net] MVSFTPEntryParser.java only halfway implemented

Wed, 6 Dec 2006 01:45:51 -0800 (PST)

I have been chasing some bugs when using the ant ftp task, and some problems
stem from the parsing of the result of the ftp list command.

The file structure of MVS is not a hierarchical filesystem, but it has a
directory concept known as partition organized datasets. These can be compared
to a single level directory.

The current parser does not take these into account.

[NET-65] [net] program hangs while trying to delete a file on a remote FTP Server after downloading same

Wed, 20 Dec 2006 02:56:02 -0800 (PST)

I am using the commons-net-1.1.0.jar to perform FTP related activities. The
process I am doing is as follows:

1. Logon to the remote FTP Server running on Solaris (which is behind a
firewall)
2. Download a file
3. Delete the remote file after successful download

But here I am facing a problem, once the file is downloaded, it does not get
deleted in the remote FTP server and the program hangs. An interrupted IO
Exception is being thrown and the program just hangs.

Any suggestions will be appreciated

[NET-3] [net][PATCH] TelnetInputStream.read sometimes hangs if reader thread is disabled

Wed, 19 Sep 2007 22:24:32 -0700 (PDT)

I'm trying to use TelnetClient with the reader thread disabled because I don't
want socket timeouts to fire during planned periods of inactivity (COM-1554).

But when the thread is disabled, I'm finding that TelnetInputStream.read
occassionally hangs when I try to read output from the server.
The problem appears to be the first while loop in __processChar, which looks
like this:

synchronized (__queue)
{
while (__bytesAvailable >= __queue.length - 1)
{
if(__threaded)
{
__queue.notify();
try

{ __queue.wait(); }

catch (InterruptedException e)

{ throw e; }

}
...
}

If you get into this loop and the threaded flag is false, you are stuck
forever. That's what's happening in my case. If I suspend the thread, I can
see that (_bytesAvailable) is 2048 and (_queue.length -
1) is also 2048, so it's an infinite loop.

I'm not sure what triggers this, but it seems to happen most often when there
is a pause in server output or a pause before I initiate the next read.

[NET-16] [net] UnixFTPEntryParser fails to parse Cygwin proftpd output when group names contain spaces

Wed, 19 Sep 2007 22:31:04 -0700 (PDT)

Running proftpd under Cygwin on Windows XP reports itself as UNIX-type server
using the "system" command:

ftp> system
215 UNIX Type: L8

Unfortunately Windows allows spaces in group names, so UnixFTPEntryParser fails
to parse directory output like the following:

ftp> dir
200 PORT command successful
150 Opening ASCII mode data connection for file list
~~rw-r~~r- 1 dkilzer Domain Users 0 Feb 13 17:20 foo.001
~~rw-r~~r- 1 dkilzer Domain Users 0 Feb 13 17:35 foo.002
226 Transfer complete.

The expected behavior is that it will find two files listed.

The actual behavior is that it reports no files in the directory.

[NET-97] [net] org.apache.commons.net.nntp.Article.getReferences() throws ClassCastException

Thu, 3 Jan 2008 11:39:33 -0800 (PST)

Hello,

org.apache.commons.net.nntp.Article.getReferences()throws a ClassCastException
if there exist references (added by addReference).

return (String[]) list.toArray(); contains an unsupported cast operation
Object[] -> String[]

Secondly:

int terminator = references.toString().indexOf(':');
StringTokenizer st =
new StringTokenizer(references.substring( terminator), "\t");

lets the first reference start with ":" which is not expected.

best Regards,
Oliver.

[NET-33] [net] __openDataConnection does not close ServerSocket after server.accept() timesout

Wed, 19 Sep 2007 22:31:07 -0700 (PDT)

In org.apache.commons.net.ftp.FTPClient
in method "protected Socket openDataConnection(int command, String arg) throws
IOException" after server.accept() times out, it leaves the socket open in
listening mode and just progates the exception. It should close the socket
before propogating the exception.

// For now, let's just use the data timeout value for waiting for
// the data connection. It may be desirable to let this be a
// separately configurable value. In any case, we really want
// to allow preventing the accept from blocking indefinitely.
if (__dataTimeout >= 0)
server.setSoTimeout(__dataTimeout);
try{ socket = server.accept(); }catch(SocketTimeoutException ste){ server.close(); throw ste; }
server.close();
}
else
{ .....
.....

[NET-57] [net] How to implement FTPS extending FTPClient, from a diferente package...

Tue, 16 May 2006 05:06:06 -0700 (PDT)

Hi everybody, I'm Jose from Spain.

I make an implement of FTPS: using
http://sourceforge.net/projects/ufsc implementation (which use a new
class, created by UFSC, org.apache.commons.net.ftp.FtpsClient that
extends org.apache.commons.net.ftp.FTPClient), with some minor
modification to adapt Java 1.3 and solve some fix with PASV transfer
(modification and fix, that i comunicate to the author).

I try to build FtpsClient under diferent packege, then i found that
couldn't do it because, in org.apache.commons.net.ftp.FTP the
variables

BufferedReader _controlInput;
BufferedWriter _controlOutput;

were declare with packege visibility, and FtpsClient use this, to
implement securety
connection to SSLSocket. Something like this:

this._controlInput = new BufferedReader(new
InputStreamReader(socket.getInputStream(), getControlEncoding()));
this._controlOutput = new BufferedWriter(new
OutputStreamWriter(socket.getOutputStream(), getControlEncoding()));

Because of this, FtpsClient, in UFSC, is under org.apache.commons.net.ftp.

Then the solution I adopt, was copy (and minor modify) FTPClient and
FTP from org.apache.commons.net.ftp in my own package, and extends
FtpsClient, from my own FTPClient, to make it in a difetent pakage...

And my suggestion is: It could be possible, for future version, declare
protected, for simplify the extension of api, to implement FTPS, or other future
protocol... in diferent package...?

as well, could by a setter, for this variables, to assing then the socket stream...

Thanks to all.

[NET-31] [net] Freeze during FTP connect

Tue, 29 Jan 2008 07:33:33 -0800 (PST)

Several times a day a Java process open FTP connections (using Commons Net) and
some times (approximately twice a week) the process hang until I kill it.
By looking at the dump it seems the lock appears during the connection opening
but I have no clue why it happens.

Here are the information I have :

-------------------------------
FTP client :

OS "Red Hat Enterprise Linux ES release 3 (Taroon Update 2)"
Java j2sdk1.4.2_05

FTP server on windows

-------------------------------

Thread dump get through kill -3 on java process :

Full thread dump Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode):

"Thread-1" daemon prio=1 tid=0x081e2cc0 nid=0x72c5 runnable [a926e000..a926e87c]
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:183)
at java.io.BufferedInputStream.read(BufferedInputStream.java:201)

locked <0xaadc0d80> (a java.io.BufferedInputStream)
at java.io.FilterInputStream.read(FilterInputStream.java:66)
at java.io.PushbackInputStream.read(PushbackInputStream.java:120)
at
org.apache.commons.net.io.FromNetASCIIInputStream.__read(FromNetASCIIInputStream.java:75)
at
org.apache.commons.net.io.FromNetASCIIInputStream.read(FromNetASCIIInputStream.java:170)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:183)
at java.io.BufferedInputStream.read(BufferedInputStream.java:201)
locked <0xaadc0028> (a org.apache.commons.net.telnet.TelnetInputStream)
at
org.apache.commons.net.telnet.TelnetInputStream.__read(TelnetInputStream.java:114)
at
org.apache.commons.net.telnet.TelnetInputStream.run(TelnetInputStream.java:535)
at java.lang.Thread.run(Thread.java:534)

"Signal Dispatcher" daemon prio=1 tid=0x0809c440 nid=0x72c5 waiting on condition
[0..0]

"Finalizer" daemon prio=1 tid=0x08097aa0 nid=0x72c5 in Object.wait()
[aabbd000..aabbd87c]
at java.lang.Object.wait(Native Method)

waiting on <0xab22b7a8> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:111)
locked <0xab22b7a8> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:127)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)

"Reference Handler" daemon prio=1 tid=0x08096ef8 nid=0x72c5 in Object.wait()
[aac3e000..aac3e87c]
at java.lang.Object.wait(Native Method)

waiting on <0xab22b810> (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:429)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:115)
locked <0xab22b810> (a java.lang.ref.Reference$Lock)

"main" prio=1 tid=0x0805ba20 nid=0x72c5 in Object.wait() [bfff9000..bfff9eec]
at java.lang.Object.wait(Native Method)

waiting on <0xaad40000> (a [I)
at java.lang.Object.wait(Object.java:429)
at
org.apache.commons.net.telnet.TelnetInputStream.read(TelnetInputStream.java:339)
locked <0xaad40000> (a [I)
at
org.apache.commons.net.telnet.TelnetInputStream.read(TelnetInputStream.java:466)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:220)
at java.io.BufferedInputStream.read(BufferedInputStream.java:277)
locked <0xaad42108> (a java.io.BufferedInputStream)
at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:408)
at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:450)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:182)
locked <0xaad42988> (a java.io.InputStreamReader)
at java.io.InputStreamReader.read(InputStreamReader.java:167)
at java.io.BufferedReader.fill(BufferedReader.java:136)
at java.io.BufferedReader.readLine(BufferedReader.java:299)
locked <0xaad42988> (a java.io.InputStreamReader)
at java.io.BufferedReader.readLine(BufferedReader.java:362)
at org.apache.commons.net.ftp.FTP.__getReply(FTP.java:264)
at org.apache.commons.net.ftp.FTP.connectAction(FTP.java:335)
at org.apache.commons.net.ftp.FTPClient.connectAction(FTPClient.java:550)
at org.apache.commons.net.SocketClient.connect(SocketClient.java:163)
at org.apache.commons.net.SocketClient.connect(SocketClient.java:250)
at com.cnetchannel.common.ftp.connect(ftp.java:405)
at com.cnetchannel.dataSource.increment(dataSource.java:137)
at com.cnetchannel.dataSource.main(dataSource.java:62)

"VM Thread" prio=1 tid=0x08095c98 nid=0x72c5 runnable

"VM Periodic Task Thread" prio=1 tid=0x0809ec70 nid=0x72c5 waiting on condition
"Suspend Checker Thread" prio=1 tid=0x0809bae8 nid=0x72c5 runnable

[NET-62] [net] FTP Client fails to retrieve file list

Wed, 19 Sep 2007 22:31:10 -0700 (PDT)

[
using commons-net-1.4.1.jar
jsdk 1.4.2_08
]

a) Both ftp servers require authorization.
b) login and authorization complete successfully.
c) change of working directory completes successfully.
d) At the end is the connection log using FileZilla to connect to ftp servers.
e) Both of the fetches below fail when a file exists in directory:

FTPListParseEngine engine = this.initiateListParsing();
FTPFile[] m_files = engine.getFiles();

FTPFile[] m_files = this.listFiles();

where THIS = the org.apache.commons.net.ftp.FTPClient

Any ideas why I can't get a file list?

- - - - FileZilla Connection Log ***************
        
        I replace server names/ips with <HOST (A or B)> ***********

Status: Connecting to <HOSTA> ...
Status: Connected with <HOSTA>. Waiting for welcome message...
Response: 220 ProFTPD 1.2.10 Server (<HOSTA>) [<HOSTA>]
Command: USER myusername
Response: 331 Password required for filer.
Command: PASS ******
Response: 230 User myusername logged in.
Command: FEAT
Response: 211-Features:
Response: MDTM
Response: REST STREAM
Response: SIZE
Response: 211 End
Command: SYST
Response: 215 UNIX Type: L8
Status: Connected
Status: Retrieving directory listing...
Command: PWD
Response: 257 "/" is current directory.
Command: TYPE A
Response: 200 Type set to A
Command: PASV
Response: 227 Entering Passive Mode (<HOSTA IP LIST>).
Command: LIST
Response: 150 Opening ASCII mode data connection for file list
Response: 226 Transfer complete.
Status: Directory listing successful
Command: TYPE I
Response: 200 Type set to I
Command: PWD
Response: 257 "/" is current directory.
Command: REST 0
Response: 350 Restarting at 0. Send STORE or RETRIEVE to initiate transfer
Command: REST 0
Response: 350 Restarting at 0. Send STORE or RETRIEVE to initiate transfer
Status: Disconnected from server
Status: Connecting to <HOSTB> ...
Status: Connected with <HOSTB>. Waiting for welcome message...
Response: 220 <HOSTB> NcFTPd Server (licensed copy) ready.
Command: USER myusername
Response: 331 User myusername okay, need password.
Command: PASS **********
Response: 230-You are user #5 of 150 simultaneous users allowed.
Response: 230-
Response: 230 Restricted user logged in.
Command: FEAT
Response: 211-Extensions supported:
Response: CLNT
Response: LANG EN*
Response: MDTM
Response: MLST
Type*;Size*;Modify*;Perm;Unique;UNIX.mode*;UNIX.owner;UNIX.uid;UNIX.group;UNIX.gid;
Response: PASV
Response: REST STREAM
Response: SIZE
Response: UTF8
Response: TVFS
Response: Compliance Level: 20040701 (IETF mlst-16)
Response: 211 End.
Command: CLNT FileZilla
Response: 200 Noted.
Command: OPTS UTF8 ON
Response: 501 Option not recognized.
Command: SYST
Response: 215 UNIX Type: L8
Status: Connected
Status: Retrieving directory listing...
Command: PWD
Response: 257 "/" is cwd.
Command: TYPE A
Response: 200 Type okay.
Command: PASV
Response: 227 Entering Passive Mode (<HOSTB IP List>)
Command: LIST
Response: 150 Data connection accepted from <CLIENT>:1229; transfer starting.
Response: 226 Listing completed.
Status: Directory listing successful
Command: TYPE A
Response: 200 Type okay.
Status: Disconnected from server

[NET-13] [net] Unit tests fail for commons-net-1.4.1 with NullPointerException

Wed, 19 Sep 2007 22:31:03 -0700 (PDT)

I'm working on updating the commons-net package for Gentoo to the most recent
version, 1.4.1, and ran into a problem running the unit tests:

[junit] Testsuite: org.apache.commons.net.time.TimeTCPClientTest
[junit] Tests run: 2, Failures: 0, Errors: 1, Time elapsed: 1.093 sec

[junit] Testcase: testInitial took 0.009 sec
[junit] Testcase: testCompareTimes took 1.074 sec
[junit] Caused an ERROR
[junit] null
[junit] java.lang.NullPointerException
[junit] at
org.apache.commons.net.SocketClient.disconnect(SocketClient.java:266)
[junit] at
org.apache.commons.net.time.TimeTCPClientTest.testCompareTimes(TimeTCPClientTest.java:133)

Upon further investigation into SocketClient, I found that disconnect() tried to
close a few objects, without checking that they weren't null. Adding a simple
check for null is enough to get the tests to pass.

[NET-96] [net] commons-net 1.4.0 binaries are incorrectly compiled as JDK 1.4

Wed, 19 Sep 2007 22:31:15 -0700 (PDT)

Commons-Net is supposed to be targeting jdk 1.2, yet project.properties for the
project contains the line

maven.compile.target=1.4

Although some of the incompatibilites were cleaned up in SOURCE earlier, the
release binaries are wrong and cause problems for those who use jdk 1.3.x.

[NET-14] [net] [patch] Unable to compile with JDK 1.3

Wed, 19 Sep 2007 22:31:04 -0700 (PDT)

Hi,

due to few trivial errors the following classes of the commons-net package
does not compile with JDK 1.3.

org.apache.commons.net.nntp.Article
org.apache.commons.net.ftp.FTPClientConfig

This can cause subtle linkage errors when using commons-net 1.4 under a JVM
1.3 environment.

The problem applies to the development version too.

See the attached patches to correct the problem.

Andrea.

[NET-39] [net] Solution for ant ftp fails with Nullpointerexception when a symlink is evaluated in method checkRemoteSensitivity in FTP.java for a z/OS ftp server

Wed, 19 Sep 2007 22:31:07 -0700 (PDT)

The following code is trying to download a file from a z/OS FTP server:
<ftp action="get" server="${server}" userid="${userid}" password="${password}"
remotedir="/usr/lpp/ims/imsjava91">
<fileset dir="C:\temp">
<include name="imsjava.jar"/>
</fileset>
</ftp>

The directory in my case also contains symlinks to non Unix File Systems. For
those symlinks somehow the FTP classes are not able to obtain file information,
e.g. the following listing prints String target and array[pcounter] from method
checkRemoteSensitivity in org/apache/tools/ant/taskdefs/optional/net/FTP.java:

[ftp] getting files
[ftp] ibm drwxr-xr-x 2 OMVSKERN SYS1 8192 Feb 14 2005 IBM
[ftp] ibm ~~rw-r~~r- 2 OMVSKERN SYS1 1963 Feb 14 2005 README
[ftp] ibm drwxr-xr-x 3 OMVSKERN SYS1 8192 Feb 14 2005 cics
[ftp] ibm drwxr-xr-x 4 OMVSKERN SYS1 8192 Jun 16 13:50 dlimodel
[ftp] ibm ~~rw-r~~r- 2 OMVSKERN SYS1 267217 Jun 16 13:50 imsjava.ja
r
[ftp] ibm ~~rw-r~~r- 2 OMVSKERN SYS1 5545 Jun 16 13:50 imsjava91.
rar
[ftp] ibm drwxr-xr-x 3 OMVSKERN SYS1 8192 Feb 14 2005 lib
[ftp] ibm null

In FTP.java at line 536 it is not checked if array[pcounter] is null.

Commons-net is at 1.4.0. Apache Ant version is 1.6.2 compiled on July 16 2004. I
did not try to research the cause in the code, why the file information is null.
For me I added an if clause around lines 536-538 to check if array[pcounter] is
null and this worked great.

So I replaced lines:
if (array[pcounter].getName().equals(target) &&
pcounter != icounter) { candidateFound = false; }

with:
if (array[pcounter] != null) {
if (array[pcounter].getName().equals(target) &&
pcounter != icounter) { candidateFound = false; } }
}

I would highly appreciate to add that code to Ant, otherwise my customers will
not be able to use any Ant version for some z/OS directories.
Thank you in advance.

[NET-77] [net] MVSFTPEntryParser setRawListing

Tue, 19 Feb 2008 14:33:32 -0800 (PST)

The MVSFTPEntryParser is not setting the raw listing in the FTPFile that it
creates. The toString on FTPFile returns this value which causes a NPE when
trying to list files via ant.

Also it is creating an FTPFile for the header ("Volume Unit...") that it
receives from the host. This also causes a problem with the list function in ant
because it receives 2 entries when requesting a listing for 1 file. Ant
(probably wrongfully) is just taking the first entry in the array that it
receives back so you never get your file names.

The following code is how I got it to work...

private static final String HEADER = "Volume Unit Referred Ext Used Recfm
Lrecl BlkSz Dsorg Dsname";

...

public FTPFile parseFTPEntry(String entry)
{
FTPFile f = null;
if (matches(entry) && !entry.trim().equals(HEADER))

{ f = new FTPFile(); String dataSetName = group(2); f.setType(FTPFile.FILE_TYPE); f.setName(dataSetName); f.setRawListing(entry); return (f); }

return null;
}

[NET-37] [net] listFiles() doesn't return anything if ftp server is configured in french

Wed, 19 Sep 2007 22:31:07 -0700 (PDT)

the FTPClient.listFiles() method returns an empty FTPFile[] array if the FTP
server is localized in french. The output of an "ls -l" command is not the same
as in english

french => drwxrwxrwx 5 user group 256 27 jul 14:48 toto
english => drwxrwxrwx 5 user group 256 Jul 27 14:48 toto

The parser gets confused because of the date not being displayed in the same way
("27 jul" vs "Jul 27")

[NET-63] [net] NTFTPEntryParser parses directory names starting with a number followed by space incorrectly.

Wed, 19 Sep 2007 22:31:11 -0700 (PDT)

When I used FTPClient.listFiles() with MS FTP Server I found that directories with names starting with a
number followed by space being parsed incorrectly. But when I browse above-mentioned server with
Internet Explorer or with Total Commander’s built-in ftp client directory names are shown correctly.
Now look at the following failing test. (It should be added to NTFTPEntryParserTest class):

public void testDirectoryBeginningWithNumberFollowedBySpaces() throws Exception

{ FTPFile f = getParser().parseFTPEntry("12-03-96 06:38AM <DIR> 123 xyz"); assertEquals("name", "123 xyz", f.getName()); }

Junit output:
…
[junit] name expected:<123 ...> but was:<...>
[junit] junit.framework.ComparisonFailure: name expected:<123 ...> but was:<...>
…

The following patch fixes the problem:

Index: jakarta-commons/net/src/java/org/apache/commons/net/ftp/parser/NTFTPEntryParser.java
===============================================================
====
RCS file: /home/cvspublic/jakarta-commons/net/src/java/org/apache/commons/net/ftp/parser/
NTFTPEntryParser.java,v
retrieving revision 1.19
diff -u -r1.19 NTFTPEntryParser.java
— jakarta-commons/net/src/java/org/apache/commons/net/ftp/parser/NTFTPEntryParser.java
2 Jan 2005 03:17:50 -0000 1.19
+++ jakarta-commons/net/src/java/org/apache/commons/net/ftp/parser/NTFTPEntryParser.java
13 Jun 2005 17:26:16 -0000
@@ -39,8 +39,7 @@
*/
private static final String REGEX =
"(\\S+)\\s+(\\S+)
s+"

+ "(<DIR>)?
s*"
+ "([0-9]+)?
s+"
+ + "(?<DIR>)|([0-9]+))
s+"
+ "(
S.*)";

/**

[NET-59] [net] NullpointerException on FTPClient.disconnect() if an Exception occured while FTPClient.connect

Wed, 20 Dec 2006 03:01:44 -0800 (PST)

Hello,

think this bug is the same (or at least similiar) to the following one:
http://issues.apache.org/bugzilla/show_bug.cgi?id=26296
but since I was not sure, I opened it as a seperate report.

Versions affected: commons-net-1.2.2, think also commons-net-1.4.0

Problem: If an exception occures while FTPClient.connect() is running, a call to
FTPClient.disconnect() in a finally-block might throw a NullPointerException.
I am pretty shure, that this might cause some Threads so keep alive, also they
cannot be interrupted anymore.

Reason: This happens since TelnetClient.disconnect() does not check whether the
Streams (__input and __ouput) it tries to close are NULL or not.
Normally it is sufficent to check FTPClient.isConnected(), but if a exceptions
is thrown after SocketClient._connectAction has been excecuted, SocketClient.
isConnected is set to true, so the check will indicate that the connection is
alive.

Christian

[NET-83] [net] FTP timestamp: year recognition

Reference — Sun, 9 Mar 2008 15:43:53 -0700 (PDT)

org.apache.commons.net.ftp.parser.FTPTimestampParserImpl

public Calendar parseTimestamp(String timestampStr)
:
if (working.after(now)) { working.add(Calendar.YEAR, -1); }

If system date of the remote machine is ahead of local machine, the code above
does not work well. For example, when the system date of local machine is five
minutes later than date of file at the remote machine, it is recognized as the
file a year ago.

LOCAL SYSDATE:Jun/02/2005 14:00
File TimeStamp
Jun/02 14:05 -~~recognized as~~-> Jun/02/2004 14:05

The date format is switched after six months, so I think that the code above
shuold be changed as following:

// s m h d half-year
// 1000*60*60*24*183=15811200000ms
long wkt = working.getTimeInMillis();
long nwt = now.getTimeInMillis();
if (wkt > (nwt+15811200000L)) { working.add(Calendar.YEAR, -1); } }

[NET-71] [net][PATCH] "MVS is the operating system of this server. FTP Server is running on z/OS."

Wed, 19 Sep 2007 22:31:11 -0700 (PDT)

Jeff Nadler created the original fix to this issue and I wrote the test case. I
will post the patch directly.

[NET-55] [net] NTP port parameter ignored

Wed, 19 Sep 2007 22:31:10 -0700 (PDT)

The port parameter of the NTPUDPClient#getTime(java.net.InetAddress host, int
port) call is not regarded in the implementation. The default port (123) is
used regardless of which port number is given in the call.

[NET-104] [net] POP3Client ProtocolCommandListener protocolReplyReceived method event.getMessage() is empty/blank

Wed, 19 Sep 2007 22:31:16 -0700 (PDT)

Using POP3Client.addProtocolCommandListener, when the listener's
protocolReplyReceived method is called with a ProtocolCommandEvent object, the
getMessage() method of this object returns a blank string. It should return the
reply string. Caused by POP3.__getReply() calling the listener before it has
saved the reply string in _replyLines.

Pseudocode example:

public class TestPOP3 implements ProtocolCommandLister
{
public void connect()

{ POP3Client client = new POP3Client(); client.addProtocolCommandListener(this); client.connect(emailServer); client.login(emailUsername, emailPassword); client.disconnect(); }

public void protocolCommandSent(ProtocolCommandEvent vent)

{ log.debug(">" + event.getMessage()); }

public void protocolReplyReceived(ProtocolCommandEvent vent)

{ // bug: event.getMessage() is always an empty string ere log.debug("<" + event.getMessage()); }

}

[NET-105] [net] FTP Parsing off in Net Components for ACL

Wed, 19 Sep 2007 22:31:16 -0700 (PDT)

If a directory has a access control list tied to it, when a directory listing is
spit out, a plus is appended onto the end of the permissions. This causes
parsing of the file fails. Below are two patches that solves this. The first
is for the test file under
/net/trunk/src/test/org/apache/commons/net/ftp/parser/. The second is the
actual parser that is under /net/trunk/src/java/org/apache/commons/net/ftp/parser.

Index: UnixFTPEntryParserTest.java
===================================================================
— UnixFTPEntryParserTest.java (revision 155093)
+++ UnixFTPEntryParserTest.java (working copy)
@@ -24,7 +24,7 @@

/**

@author <a href="mailto:scohen@apache.org">Steve Cohen</a>

* @version $Id: UnixFTPEntryParserTest.java,v 1.15 2004/09/14 01:47:17 scohen
Exp $
+ * @version $Id$
*/
public class UnixFTPEntryParserTest extends FTPParseTestFramework
{
@@ -45,6 +45,7 @@

private static final String[] goodsamples =
{ + "-rw-r--r-- 1 500 500 21 Aug 8 14:14 JB3-TES1.gz", "-rwxr-xr-x 2 root root 4096 Mar 2 15:13 zxbox", "drwxr-xr-x 2 root root 4096 Aug 24 2001 zxjdbc", @@ -70,6 +71,8 @@ "-rwSr-Sr-- 1 500 500 0 Mar 25 08:22 testSuid", "-rwsr-sr-- 1 500 500 0 Mar 25 08:23 testSuidExec", "-rwsr-sr-- 1 500 500 0 Mar 25 0:23 testSuidExec2", + "drwxrwx---+ 23 500 500 0 Jan 10 13:09 testACL", + "-rw-r--r-- 1 1 3518644 May 25 12:12 std" };

Index: UnixFTPEntryParser.java
===================================================================
— UnixFTPEntryParser.java (revision 155093)
+++ UnixFTPEntryParser.java (working copy)
@@ -26,7 +26,7 @@

This class is based on the logic of Daniel Savarese's
DefaultFTPListParser, but adapted to use regular expressions and to fit the
new FTPFileEntryParser interface.

* @version $Id: UnixFTPEntryParser.java,v 1.21 2005/01/02 03:17:50 scohen Exp $
+ * @version $Id$

@see org.apache.commons.net.ftp.FTPFileEntryParser FTPFileEntryParser (for
usage instructions)
*/
public class UnixFTPEntryParser extends ConfigurableFTPFileEntryParserImpl
@@ -65,7 +65,7 @@
*/
private static final String REGEX =
"([bcdlfmpSs-])"

+
"(((r|~~)(w|~~)([xsStTL-]))((r|~~)(w|~~)([xsStTL-]))((r|~~)(w|~~)([xsStTL-])))
s+"
+ +
"(((r|~~)(w|~~)([xsStTL-]))((r|~~)(w|~~)([xsStTL-]))((r|~~)(w|~~)([xsStTL-])))\\+?
s+"
+ "(\\d+)
s+"
+ "(\\S+)
s+"
+ "(?\\S+)
s+)?"

[NET-68] [net] TFTPClient's send file discards last ack

Blocker — Wed, 16 Jan 2008 16:36:11 -0800 (PST)

TFTPClient reads all acks just fine except the last-one when sending a file. I
figured this out when I tried to use the same TFTPClient-instance for something
else (reading a file) after sending a file. This ack was next in the buffer and
some exception was thrown (don't remember which anymore).

I fixed this for myself using a flag (lastAckWait). Here is a the result of
diff-command:

diff -u TFTPClient.java.original TFTPClient.java.patched
— TFTPClient.java.original 2004-12-28 15:02:37.235997984 +0200
+++ TFTPClient.java.patched 2004-12-28 15:09:14.516602152 +0200
@@ -372,6 +372,7 @@

dataLength = lastBlock = hostPort = bytesRead = 0;
block = 0;
+ boolean lastAckWait = false;

if (mode == TFTP.ASCII_MODE)
input = new ToNetASCIIInputStream(input);
@@ -455,7 +456,10 @@
if (lastBlock == block)

{ ++block; - break _receivePacket; + if (lastAckWait) + break _sendPacket; + else + break _receivePacket; }

else

{ @@ -501,9 +505,8 @@ data.setData(_sendBuffer, 4, offset - 4); sent = data; }

while (dataLength == 0);
+ while (dataLength == 0 || lastAckWait);

bufferedSend(sent);
endBufferedOps();
}

By the way we have implemented a TFTP server also (heavily unit-tested). I could
try to contribute it back if it fits in commons net. There was some talk in the
web-pages of doing only client-side stuff for commons-net.

-Perttu

[NET-22] [net] FTP component: FTPFile does not initialize miliseconds correctly

Wed, 19 Sep 2007 22:31:05 -0700 (PDT)

Hi, I have been working with the FTP utilities and was saving the filename and
lastModifiedTime (as taken from FTPFile.lastModifiedTime()) and had a problem
where I would query a directory, save those two parameters for each of the
files, then later on query the same directory (which in my test case has not
changed any) and I would find that the FTPFile.lastModifiedTime() objects did
not match.

In looking furthur into it I found that the calendar objects returned by this
function were off by a some random number of milliseconds, however it looked
like the hour, minutes, and all other times of the calendar were correct, it
was only the milliseconds.

Drilling furthur into the source code for the Commons FTP components I think I
see what was overlooked to cause this condition.

In version 1.2.2 if you look at the UnixFTPEntryParser.java source (I believe
this is the parser being used for my WSFTP server I am running, you can
download this ftp server from download.com, I am using this for my development
environment), looking on line 185 you have the following code:

Calendar cal = Calendar.getInstance();
cal.set(Calendar.SECOND, 0);
cal.set(Calendar.MINUTE, 0);
cal.set(Calendar.HOUR_OF_DAY, 0);

I see that you are initially creating a new calendar instance, which, by
default sets the calendar to the current time. Then you update the seconds,
minutes, and hour of dat, however you are not initializing the miliseconds,
hence the miliseconds vary between different instantiations of the same ftp
entry. This causes the Calendar.equals() function to indicate that the two
times are different, though they should be equal.

If you add:
cal.set(Calendar.MILLISECOND, 0);

I think you eliminate this problem.

Best regards,
David

[NET-5] [net] FTP Parser will fail with localized directory listings

Wed, 19 Sep 2007 22:31:02 -0700 (PDT)

Various parsers in the org.apache.commons.net.ftp.parser package assume english abbreviations for
months; such as
private static final String MONTHS =
"(Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec)";

However, some server return localized versions of the above such as Okt for October in German.

[NET-79] extra byte in WRQ TFTP packet

Wed, 19 Sep 2007 22:31:12 -0700 (PDT)

I obeserved that each tftp "write request" packet had two bytes with value x00
at the end of the packet.
e.g: 00 02 2f 6d 69 62 2f 63 6f 6e 66 69 67 00 6e 65 74 61 73 63 69 69 00 00

My tftp server (tftp4java) rejects this type WRQ packets.
I checked the RFC1350 and there I found:

2 bytes string 1 byte string 1 byte
-----------------------------------------------
RRQ/ | 01/02 | Filename | 0 | Mode | 0 |
WRQ -----------------------------------------------

Gerard.

[NET-67] [net] Problem calculating total article count

Wed, 19 Sep 2007 22:31:11 -0700 (PDT)

I am using Commons Net 1.2.2

When you ask for the list of newsgroups of a NNTP Server, the framework doesn't
calculate correctly the total article count when that specific newsgroup has no
articles.

For example, the NNTP Server answers something like this:

org.javahispano.j2ee 0 0 y

then, debugging the source code of class:

org.apache.commons.net.nntp.NNTPClient

I found the problem in method:

private NewsgroupInfo __parseNewsgroupListEntry(String entry)

where it does:

...
result._setNewsgroup(tokenizer.nextToken());
last = tokenizer.nextToken();
first = tokenizer.nextToken();
permission = tokenizer.nextToken();

try

{ lastNum = Integer.parseInt(last); firstNum = Integer.parseInt(first); result._setFirstArticle(firstNum); result._setLastArticle(lastNum); result._setArticleCount(lastNum - firstNum + 1); }

catch (NumberFormatException e)

{ return null; }

The proble is in this line:

result._setArticleCount(lastNum - firstNum + 1);

where if lastNum is 0 and firstNum is 0, it sais that the newsgroup has 1
article. I understand the code should add a control line where it double check
if lastNum and firstNum are 0. Right?

[NET-69] UnixFTPEntryParser.java fails to properly set MILLISECONDS field on FTPFile

Wed, 19 Sep 2007 22:31:11 -0700 (PDT)

[This defect may affect other parsers too -- I haven't checked.]

On listings returned from UNIX FTP servers, only the hour and minute of the
modification time of a given FTPFile is shown. UnixFTPEntryParser.java does the
following when encountering such a listing:

Calendar cal = Calendar.getInstance();
cal.set(Calendar.SECOND, 0);
cal.set(Calendar.MINUTE, 0);
cal.set(Calendar.HOUR_OF_DAY, 0);

try
{
int pos = MONTHS.indexOf(mo);
int month = pos / 4;

if (null != yr)

{ // it's a year cal.set(Calendar.YEAR, Integer.parseInt(yr)); }

else
{
// it must be hour/minute or we wouldn't have matched
int year = cal.get(Calendar.YEAR);
// if the month we're reading is greater than now, it must
// be last year
if (cal.get(Calendar.MONTH) < month)

{ year--; }

cal.set(Calendar.YEAR, year);
cal.set(Calendar.HOUR_OF_DAY, Integer.parseInt(hr));
cal.set(Calendar.MINUTE, Integer.parseInt(min));
}
cal.set(Calendar.MONTH, month);

cal.set(Calendar.DATE, Integer.parseInt(da));
file.setTimestamp(cal);

Unfortunately, the code does not properly set the MILLISECOND field of the
original Calendar object. This means the MILLISECOND field is dependent upon the
system time that the object is actually created. Therefore, the FTPFile's
timestamp is wrong.

I propose that the above code be patched to add a cal.set(Calendar.MILLISECOND, 0);

[NET-6] FTPClient.listFiles method returns null for some files

Wed, 19 Sep 2007 22:31:02 -0700 (PDT)

There's problem in regullar expression in class
org.apache.commons.net.ftp.parser.UnixFTPEntryParser which causes that files
with lastmodified attribute from 0 to 1 a.m. are not listed by ftpclient
listFiles method.

Example:
This file is listed correctly:
-rwxrwxrwx 1 owner group 5127 Sep 24 11:44 somefile_tst_200409192_v105_breq.xml
For this, listFiles method returns null:
-rwxrwxrwx 1 owner group 5127 Sep 20 0:32 somefile_tst_200409192_v101_breq.xml

Problem seems to be in:
private static final String REGEX =
"([bcdlfmpSs-])"
+ "(((r|~~)(w|~~)([xsStTL-]))((r|~~)(w|~~)([xsStTL-]))((r|~~)(w|~~)([xsStTL-])))
s+"
+ "(\\d+)
s+"
+ "(\\S+)
s+"
+ "(?\\S+)
s+)?"
+ "(\\d+)
s+"
+ MONTHS + "
s+"
+ "((?:[0-9])|(?:[0-2][0-9])|(?:3[0-1]))
s+"
+ "((\\d\\d\\d\\d)|((?:[01]\\d)|(?:2[0123])|(?:[1-9])):([012345]\\d))
s+"
+ "(\\S+)(
s*.*)";

where correct expression should be like this (0 insted of 1):

private static final String REGEX =
"([bcdlfmpSs-])"
+ "(((r|~~)(w|~~)([xsStTL-]))((r|~~)(w|~~)([xsStTL-]))((r|~~)(w|~~)([xsStTL-])))
s+"
+ "(\\d+)
s+"
+ "(\\S+)
s+"
+ "(?\\S+)
s+)?"
+ "(\\d+)
s+"
+ MONTHS + "
s+"
+ "((?:[0-9])|(?:[0-2][0-9])|(?:3[0-1]))
s+"
+ "((\\d\\d\\d\\d)|((?:[01]\\d)|(?:2[0123])|(?:[0-9])):([012345]\\d))
s+"
+ "(\\S+)(
s*.*)";

[NET-1] commons-net 1.2.2 does not compile with JDK 1.5

Wed, 19 Sep 2007 22:31:01 -0700 (PDT)

It uses 'enum' which is a restricted keyword in JDK 1.5; you have to compile it
with -source 1.4. I will attach a patch

[NET-52] TFTPClient.setMaxTimeouts() param check broken

Wed, 19 Sep 2007 22:31:09 -0700 (PDT)

The input check on this method inspects the instance variable it is
going to set not the input received.

Index: TFTPClient.java
===================================================================
RCS file: /home/cvspublic/jakarta-commons/net/src/java/org/apache/commons/net/
tftp/TFTPClient.java,v
retrieving revision 1.14
diff -u -r1.14 TFTPClient.java
— TFTPClient.java 29 Jun 2004 04:54:31 -0000 1.14
+++ TFTPClient.java 23 Sep 2004 13:55:24 -0000
@@ -86,7 +86,7 @@
***/
public void setMaxTimeouts(int numTimeouts)
{

if (__maxTimeouts < 1)
+ if (numTimeouts < 1)
__maxTimeouts = 1;
else
__maxTimeouts = numTimeouts;

[NET-100] TelnetInputStream zombie thread memory leak, FTPClient TelnetClient

Tue, 16 May 2006 05:20:40 -0700 (PDT)

If myFTPClient.setReaderThread(false) and many ftp clients are instanciated
over time, the VM gets out of memory errors. The problem is that the underlying
TelnetClient's TelnetInputStream creates a new thread that it never uses (never
starts, or joins). The VM is unable to garbage collect these zombie threads.
This problem is paticularly notable given that several users have observed
hangs doing continual ftp unless setReaderThread(false). This observed on hpux
jdk 1.3 <todo lookup specific version>

Here's a patch:

cvs server: Diffing src/java/org/apache/commons/net/telnet
Index: src/java/org/apache/commons/net/telnet/TelnetClient.java
===================================================================
RCS file: /home/cvspublic/jakarta-
commons/net/src/java/org/apache/commons/net/telnet/TelnetClient.java,v
retrieving revision 1.12
diff -r1.12 TelnetClient.java
100,101c100
<
< tmp = new TelnetInputStream(input, this);
—
> tmp = new TelnetInputStream(input, this, readerThread);
Index: src/java/org/apache/commons/net/telnet/TelnetInputStream.java
===================================================================
RCS file: /home/cvspublic/jakarta-
commons/net/src/java/org/apache/commons/net/telnet/TelnetInputStream.java,v
retrieving revision 1.11
diff -r1.11 TelnetInputStream.java
56c56
< TelnetInputStream(InputStream input, TelnetClient client)
—
> TelnetInputStream(InputStream input, TelnetClient client, boolean
readerThread)
72c72,74
< __thread = new Thread(this);
—
> if (readerThread) { > __thread = new Thread(this); > }
76a79
> if (__thread==null) { return; }
498c501
< if (__thread.isAlive())
—
> if (__thread!=null && __thread.isAlive())

[NET-30] FTPClient deals badly with adverse network conditions

Wed, 19 Sep 2007 22:25:04 -0700 (PDT)

We are attempting to use the FTPClient included in commons-net 1.2.2 to write
an application which has to deal with various outages:

connection closed by server, without 421 warning
connection frozen
server temporarily unreachable
...

However, it appears that in most of these cases, FTPClient becomes easily
confused:

If the connection is closed without warning, FTPClient doesn't notice at
first: ftp.isConnected() still returns true. However, when attempting to use
such a closed connection, we do get the correct exception
(FTPConnectionClosedException), at least most of the time (occasionnally we do
get various SocketExceptions instead)
If the ftp server doesn't respond in time, FTPClient hangs forever, even
after the ftp server responds eventually
If setSoTimeout is set, and if the server doesn't respond, the following
behaviour happens:
- if the server becomes responsive again before the timeout happens, the
  client hangs until the timeout then receives SocketTimeoutException exception.
  We would prefer if the client just continued normally (as the server did
  respond before timeout)
- if on the other hand the server does not become responsive when the timeout
  happens, the client won't get any exception when timeout expires. Instead it
  will just hang. As soon as the server gets responsive again (i.e. after the
  timeout had expired), the client immediately get the exception. We would prefer
  if the client got the exception at the timeout, rather than long afterwards.

[NET-36] [net] PATCH] FTP and FTPClient changes

Sat, 8 Mar 2008 11:38:50 -0800 (PST)

I've included 3 patch files for changes I've made to the FTP andFTPClient
classes in the commons-net package.

The first patch is for the FTP class making it extend SocketClientinstead of
TelnetClient. I noticed that the behavior of theTelnetClient's input stream
reader thread was effectively ignoring thesocket's SOTimeout causing reads to
hang forever if the server decidednot to respond to a client request at all.
This should also answer oneof the goals from the TODO list:

"Divorce FTPClient from TelnetClient, getting rid of the TelnetClientthreads
which cause problems on some platforms (e.g., MacOS)."

The second patch is for an FTPTest unit test. I've covered most of thebasic
methods (connect(), disconnect(), sendCommand(), getReplyCode(),etc). Ignored
for now are the convenience methods since they all callsendCommand() underneath.
Part of the FTPTest class is a DummyFTPServerinner class which is used to
communicate to the test FTP class - don'tknow if that would be useful elsewhere
(maybe part of FTPClient unittests), so you might consider making it a utility
class for other unittests.

Finally I've attached a patch for minor changes to FTPClient:

changed __storeFile() from private to protected so that it can beused by
classes that extend FTPClient

added __storeFile(String, String) method - so that the commands itaccepts are
not limited to what's found in FTPCommand. Note: the__storeFile(int, String)
method now calls the __storeFile(String,String) method.

added openDataConnection(String, String) method - so that thecommands it
accepts are not limited to what's found in FTPCommand. Note:the
openDataConnection(int, String) method now calls
the_openDataConnection_(String, String) method.

Hopefully you'll find the changes agreeable and will incorporate theminto the
code base.

[NET-72] UnixFTPEntryParser returns null when timestamp is between 12:00am and 12:59am

Wed, 19 Sep 2007 22:31:12 -0700 (PDT)

This concerns commons.net version 1.2.2.

When I request a ftp listing from a directory with a file having a timestamp
between 12:00am and 12:59am on a Microsoft FTP Service (Version 5.0) box, the
FTPClient listFiles() method returns null for that file. Here is an example
directory listing:

-rwxrwxrwx 1 owner group 115407014 Aug 12 19:33 images_20040812.zip
-rwxrwxrwx 1 owner group 144408943 Aug 13 2:03 images_20040813.zip
-rwxrwxrwx 1 owner group 146215270 Aug 14 10:29 images_20040814.zip
-rwxrwxrwx 1 owner group 144822990 Aug 17 6:00 images_20040817.zip
-rwxrwxrwx 1 owner group 22 Aug 18 0:36 test.zip

The entry from listFiles() that corresponding text.zip will be null.

I tracked down the problem to the REGEX pattern in UnixFTPEntryParser. If I
change the expression to the following, I can get the FTPFile from the
listFiles() method.

private static final String REGEX =
"([bcdlfmpSs-])"
+ "(((r|~~)(w|~~)([xsStTL-]))((r|~~)(w|~~)([xsStTL-]))((r|~~)(w|~~)([xsStTL-])))
s+"
+ "(\\d+)
s+"
+ "(\\S+)
s+"
+ "(?\\S+)
s+)?"
+ "(\\d+)
s+"
+ MONTHS + "
s+"
+ "((?:[0-9])|(?:[0-2][0-9])|(?:3[0-1]))
s+"
// Following line changed
+ "((\\d\\d\\d\\d)|((?:[01]\\d)|(?:2[0123])|(?:[0-9])):([012345]\\d))
s+"
// Original line
//+ "((\\d\\d\\d\\d)|((?:[01]\\d)|(?:2[0123])|(?:[1-9])):([012345]\\d))
s+"
+ "(\\S+)(
s*.*)";