commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 36473] - [Net] FTPClient.storeFile keeps returning false on XP only, stores nothing to FTP server
Date Mon, 05 Sep 2005 20:33:02 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=36473>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36473





------- Additional Comments From dfs@apache.org  2005-09-05 22:33 -------
(In reply to comment #6)
> So why ISN'T an exception thrown when the program is run in an applet?  Is this
> a JVM problem?

It almost has to be a JVM problem if FileNotFoundException is not being thrown.
The code for the private native method FileInputStream.open (which is what is
ultimately called) is different for Windows and Linux.  I don't have the
native source code for JDK 1.4, but it's possible that an insufficent error
check is being performed or an incorrect flag for CreateFileW is being
used (e.g., OPEN_ALWAYS), preventing the code path that throws the
FileNotFoundException from executing.  As for connecting to the Web server,
that may be a security manager interaction resulting from the invalid file.  As
interesting as it may be to get to the real bottom of this, I have no time
to slog through Sun's JDK source code and just want to help establish
whether or not Commons Net is causing this.  I just can't find any way
the behavior could be triggered by FTPClient itself.  The host used for
passive mode is obtained from the response to the PASV command and the
local address bound to for active mode is obtained from Socket.getLocalAddress.

It may help is to print the FTP conversation with PrintCommandListener
from the examples and see what the server is telling FTPClient and whom
FTPClient thinks it is connecting to.  If FTPClient has the right host
for passive mode, yet when it creates a client socket the socket returned
is from a connection attempt to the Web server--having ignored the
supplied host--then we know it's definitely the applet execution environment
that is at fault even if we don't know the exact details of why the applet
container is doing that.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message