jigsaw created NET-546:
--------------------------
Summary: NPE because of returning wrong reply-code for
openDataConnection while performing MPUT
Key: NET-546
URL: https://issues.apache.org/jira/browse/NET-546
Project: Commons Net
Issue Type: Bug
Components: FTP
Affects Versions: 3.3
Environment: Win7, System i (IBM)
Reporter: jigsaw
Hi there,
I'm trying to transfer some data from a Windows 7 system to a System i (IBM
server, former AS/400) by using MPUT.
So what I am doing in detail:
I have got a Java client on my Windows 7 machine. There apache commons net is
in use. By using the class FTPClient I connect to an IBM machine (there is
installed V7R1).
These are the commands I fire:
ftp.login(username, password);
ftp.setFileType(FTP.BINARY_FILE_TYPE);
ftp.changeWorkingDirectory(pathname);
ftp.storeFileStream(remoteFile);
ftp.disconnect();
When performing the storeFileStream NULL is returned instead of the output
stream. Connection can be established and everything is working well.
The problem is that a wrong reply-code is checked during openDataConnection.
Let me sum up the relevant steps:
1. storeFileStream is called
2. _storeFileStream(String, String) of FTPClient gets entered
3. Then _openDataConnection_ is entered
4. Inside this method the active connection mode part is executed
5. Using IP4 the port method is called there
6. Due to calling the PORT command for FTP a new return message is generated:
“200 PORT subcommand request successful.”
7. isPositiveCompletion returns true everything is fine up to here
8. Going on with the active connection mode part this leads to the sendCommand
method where – after executing the FTP command – the __getReply(boolean) method
inside of __getReply() is called.
9. And now the issue: _controlInput_.readLine() returns the PORT message
mentioned before instead of “150 Sending file to [myFile]”. When calling
readLine again, the correct message is returned.
Why is the message important?
Getting back to _openDataConnection_ after execution of sendCommand the method
FTPReply.isPositivePreliminary checks the reply-code, which is 200 instead of
150. This will cause a fail and a returning of NULL as output stream.
That’s my guess:
There is missing a call of _controlInput_.readLine() to clear some information
messages before calling a new FTP command.
Thank you.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
