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 06:41:15 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 spamnot@polard.com  2005-09-05 08:41 -------
(In reply to comment #3) 
> Thanks for this especially detailed report.  It appears that this problem 
> appears under Windows XP only, and only when the files the system is 
attempting 
> to transfer are of 0 length.  Please confirm that. 
 
Hi Steve 
 
This is confirmed, from what I can determine. The reason of course, as detailed 
in my previous replies, is that on Windows systems the JVM could not find the 
file (due to an incorrect path specification by me) and storeFile was then 
given a FileInputStream object as source for data to transfer which was 
returning 0 bytes, because it had been constructed on an non-existing file. 
 
I suspect in Linux it will behave identically - my code worked in Linux 'cause 
the JVM COULD find the file - the different oriented slashes was the problem, 
so this issue should manifest the same way cross-platform, only in my test case 
the file COULD be found in Linux. 
  
> I'm not sure why you marked this defect as "fixed".  Nothing has been 
changed, 
> you've merely isolated the conditions under which it occurs.   
 
You are right, I stand corrected. The issue for me was resolved (i. e. my 
program started working when I made 100% sure that the file could be found in 
Windows AS WELL as Linux) but I agree that a problem might still exist in 
commons.net regarding this. 
 
>This should not be 
> happening.  It's a bug, somewhere.  Maybe in the JVM, but until we nail that 
> down, this issue should not be considered fixed and I'm reopening it. 
>  
> Can I also ask you to please go a little deeper?  If you will look at the 
> _openDataConnection_() method called from Line 388 you will see many 
conditions 
> which can cause this method to return null.  Can you please identify (perhaps 
> through use of a debugger) which line within this method is causing null to 
be 
> returned here? 
 
Unfortunately, I do not have a debugger available that can debug applets (where 
can I get one - any downloadable ones around?). The packaged jdb with the sdk 
can't debug applets. I do suspect that the method finally passing null back up 
the call chain to my app sits deeper than line 388, since, if execution is 
traced on a Windows JVM, you can see the connection attempt being made to the 
webserver, NOT the logged-into FTP server. I have desk-checked execution and I 
strongly suspect that line 477 (if using active mode) in 
 
commons-net-1.4.0-src.tar.gz/commons-net-1.4.0/src/java/org/apache/commons/net/ftp/FTPClient.java

 
might be the one that actually generates the returned null, since this line 
 
if (!FTPReply.isPositiveCompletion(port(getLocalAddress(), 
                                                    server.getLocalPort()))) 
 
must be the one that is connecting to the webserver, NOT the FTP server. Since 
it is very certain that the reply from the method call will be negative (the 
webserver is not even listening on port 20, so no cigar, even if the JVM tried 
to connect there while executing the code) so this must most -likely- be the 
point where null is returned. Maybe this just needs to be in a try...catch 
block to generate an exception if it cannot connect, and not just return null? 
 
Further, it seems that the getLocalAddress() method must then be the one that 
returns the -webserver-'s address, instead of the FTP server's address if one 
passes a zero-length resolving FileInputStream object to storeFile. 
 
If using passive mode, I suspect line 520 is the one causing the null to come 
back to the calling method, since the webserver will not give a positive reply: 
 
 if (!FTPReply.isPositivePreliminary(sendCommand(command, arg))) 
            { 
                socket.close(); 
                return null; 
            } 
 
Note that I tested both with active and passive mode, and the trace in the Java 
console and results where the same - the JVM tried to connect to the webserver, 
and the storeFile method still reported null as a result value. 
 
So in summary, the issue seems to be that if storeFile gets a FileInputStream 
object that is constructed on a file that does not exist, no exceptions are 
thrown, and methods called inside of storeFile will then try to connect to the 
server containing the applet. This, logically, happens in BOTH the Windows and 
Linux JVM - by chance in Linux, with the different oriented slashes, the JVM 
could find the file (due to my admittedly badly-written code), while in 
Windows, it could not. 
 
If you need more info feel free to mail me at any time. Thanks for responding, 
Steve! 

-- 
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