2 characters in the response code 226 disappear

Question

When I transfer a file using an application that in turn uses edtftp I often but not always get the following error:

Put file C:\Documents and Settings\Administrator\Local Settings\Temp\20061102094002.gpg remote 20061102094002.gpg
DEBUG [com.enterprisedt.net.ftp.FTPControlSocket] 2 nov 2006 09:41:56.268 : ---> PASV
DEBUG [com.enterprisedt.net.ftp.FTPControlSocket] 2 nov 2006 09:41:56.299 : 227 Entering Passive Mode (83,140,32,143,234,251).
DEBUG [com.enterprisedt.net.ftp.FTPControlSocket] 2 nov 2006 09:41:56.331 : ---> STOR 20061102094002.gpg
DEBUG [com.enterprisedt.net.ftp.FTPControlSocket] 2 nov 2006 09:41:56.346 : 150 Ok to send data.
DEBUG [com.enterprisedt.net.ftp.FTPClient] 2 nov 2006 09:50:02.659 : Transferred 56503071 bytes to remote host
DEBUG [com.enterprisedt.net.ftp.FTPControlSocket] 2 nov 2006 09:50:02.784 : 6 File receive OK.

com.enterprisedt.net.ftp.FTPException: le receive OK.
   at com.enterprisedt.net.ftp.FTPControlSocket.validateReply(FTPControlSocket.java:872)
   at com.enterprisedt.net.ftp.FTPClient.validateTransfer(FTPClient.java:1358)
   at com.enterprisedt.net.ftp.FTPClient.put(FTPClient.java:1328)
   at com.enterprisedt.net.ftp.FTPClient.put(FTPClient.java:1313)
   at com.enterprisedt.net.ftp.FTPClient.put(FTPClient.java:1291)

It looks as if 2 characters in the response code 226 disappear in a mystical way. What can be wrong?

Thanks/Mikael

Answer 1

Post the results of using command-line FTP. When you first start ftp.exe, type 'debug' to get command debugging.

Answer 2

Post the results of using command-line FTP. When you first start ftp.exe, type 'debug' to get command debugging.

I have very difficult to do that. This is a special application which does nightly backup to a remote server. The rules which files to transfer (after encryption) are somewhat complicated and this is why I had to write a special application. If I run smaller files or even if I run the same backup manually starting it at some other time then it often works ok. Sometimes it even works when run as scheduled.

I have been looking into your edtftp source code and it seems that you actually read this truncated string when you read the Java socket input stream. Can it be Java runtime or underlying XP runtime or network card/driver?

Another idea, does FTPControlSocket use UDP or TCP for commands and responses?

Thanks/Mikael

Answer 3

Can it be Java runtime or underlying XP runtime or network card/driver?

That seems unlikely. At least I've never heard of such a problem.

Another idea, does FTPControlSocket use UDP or TCP for commands and responses?

It's all TCP.

When the beginning of a string gets cut off like that it's often because the previous string was not read correctly. For example, if the following two lines are being read:

12345678\n
ABCDEFGH

and, for whatever reason, the first is read as '12345678\nABC' then the second would be read as 'DEFGH'. Could you put in some debug to check if this might be what's happening?

- Hans (EDT)

Answer 4

Could you put in some debug to check if this might be what's happening?

- Hans (EDT)

I'm mailing to you (via email) edtftp log from a run when this error occurs and full Ethereal capture for control socket port during the run.

The log shows what edtftp is reading from Java socket. The line is truncated but previous line is ok. The capture shows that the server sent correct line. This starts to smell like system error of some kind.

Thanks/Mikael

Answer 5

This is certainly an unusual problem. I wonder if it has anything to do with the retransmitted packets shown at the end of the ethereal dump. It seems that the original packets weren't acknowledged.

It might be worth trying active mode transmissions if the server permits it.

What OS is the client running on? And what version of the JRE?

Answer 6

This is certainly an unusual problem. I wonder if it has anything to do with the retransmitted packets shown at the end of the ethereal dump. It seems that the original packets weren't acknowledged.

It might be worth trying active mode transmissions if the server permits it.

What OS is the client running on? And what version of the JRE?

Yes, I