Occasional JPEG corruption with edtFTPNet Free version

Question

I am using edtFTPNet Free version 2.2.2 with VB.NET 2010. My program needs to upload small jpeg files (about 50KB) via FTP to my website. It does this quite frequently; sometimes 1 file every minute. A small javascript file is also transferred with every image. About 1 image in 10 suffers some corruption like this:

[ img ]

Please ignore the noise bars! It's the light brown coloured area at the bottom of the image I am referring to. Sometimes reloading the image from the server clears the corruption, but more often it does not. On many (but not all) occasions, the corruption disappears after several more images have been transferred, almost as if some data has been left in a buffer which is eventually transferred after several other FTP transactions have been completed. Any suggestions on debugging this problem?

Thanks,

Paul.

Answer 1

The best thing to do is to enabled logging at the DEBUG level and analyse the log-messages for a corrupted transfer. Post it here if you'd like some help analysing it.

- Hans (EnterpriseDT)

Answer 2

The best thing to do is to enabled logging at the DEBUG level and analyse the log-messages for a corrupted transfer. Post it here if you'd like some help analysing it.

- Hans (EnterpriseDT)

Thanks. I will try to find out how to do that.

Answer 3

Not sure if I am logging correctly, but I can see no difference between successful transfers and those that show corruption. Here is a section of log in case it shows some "setting" that could be changed to get more consistent transfers:

DEBUG [FTPConnection] 23 Sep 2012 15:40:04.170 : Set LocalDirectory='C:\Users\Paul\Documents\VB.NET 2012\SIGMA10\SSTV_RX_Images\bin\Debug'
DEBUG [FTPClient] 23 Sep 2012 15:40:04.170 : Connecting to ftp.classicsstv.com:21
DEBUG [HostNameResolver] 23 Sep 2012 15:40:04.170 : Resolving ftp.classicsstv.com
DEBUG [HostNameResolver] 23 Sep 2012 15:40:04.170 : ftp.classicsstv.com resolved to 79.170.44.37
INFO [BaseSocket] 23 Sep 2012 15:40:04.170 : Connecting to 79.170.44.37:21 with timeout 120000 ms
DEBUG [BaseSocket] 23 Sep 2012 15:40:04.170 : Successfully connected to 79.170.44.37:21
DEBUG [FTPControlSocket] 23 Sep 2012 15:40:04.170 : Setting socket timeout=120000
INFO [FTPControlSocket] 23 Sep 2012 15:40:04.170 : Command encoding=System.Text.SBCSCodePageEncoding
DEBUG [FTPControlSocket] 23 Sep 2012 15:40:04.170 : StrictReturnCodes=False
DEBUG [FTPControlSocket] 23 Sep 2012 15:40:04.388 : 220 FTP server ready
DEBUG [FTPConnection] 23 Sep 2012 15:40:04.388 : Connected to ftp.classicsstv.com (instance=12)
DEBUG [FTPControlSocket] 23 Sep 2012 15:40:04.388 : ---> USER classicsstv.com
DEBUG [FTPControlSocket] 23 Sep 2012 15:40:04.435 : 331 Password required for classicsstv.com
DEBUG [FTPControlSocket] 23 Sep 2012 15:40:04.435 : ---> PASS ********
DEBUG [FTPControlSocket] 23 Sep 2012 15:40:04.497 : 230 Login successful. Username & password correct; FTP unlocked.
DEBUG [FTPConnection] 23 Sep 2012 15:40:04.497 : Successfully logged in
INFO [FTPConnection] 23 Sep 2012 15:40:04.497 : Auto FEAT disabled
DEBUG [FTPControlSocket] 23 Sep 2012 15:40:04.497 : ---> TYPE I
DEBUG [FTPControlSocket] 23 Sep 2012 15:40:04.544 : 200 Type set to I
DEBUG [FTPControlSocket] 23 Sep 2012 15:40:04.544 : ---> PWD
DEBUG [FTPControlSocket] 23 Sep 2012 15:40:04.575 : 257 "/" is the current directory
DEBUG [FTPConnection] 23 Sep 2012 15:40:04.575 : UploadFile(C:\MMSSTV\History\History_for_test\201209041243.jpg,public_html/sigma_test/201209041243.jpg,False)
INFO [FTPConnection] 23 Sep 2012 15:40:04.575 : Cancel resume
DEBUG [FTPControlSocket] 23 Sep 2012 15:40:04.575 : ---> REST 0
DEBUG [FTPControlSocket] 23 Sep 2012 15:40:04.591 : 502 Command REST not allowed by policy.
INFO [FTPControlSocket] 23 Sep 2012 15:40:04.591 : Expected reply codes = [350] (strict=False)
DEBUG [FTPClient] 23 Sep 2012 15:40:04.591 : REST failed which is ok (Command REST not allowed by policy. (code=502))
DEBUG [FTPControlSocket] 23 Sep 2012 15:40:04.591 : ---> PASV
DEBUG [FTPControlSocket] 23 Sep 2012 15:40:04.638 : 227 Entering Passive Mode (79,170,44,37,243,92).
DEBUG [FTPControlSocket] 23 Sep 2012 15:40:04.638 : Server supplied address=79.170.44.37
DEBUG [FTPControlSocket] 23 Sep 2012 15:40:04.638 : Server supplied port=62300
DEBUG [FTPControlSocket] 23 Sep 2012 15:40:04.638 : autoPassiveIPSubstitution=True
DEBUG [FTPControlSocket] 23 Sep 2012 15:40:04.638 : remoteAddr=79.170.44.37
DEBUG [FTPControlSocket] 23 Sep 2012 15:40:04.638 : Substituting server supplied IP (79.170.44.37) with remote host IP (79.170.44.37)
DEBUG [FTPControlSocket] 23 Sep 2012 15:40:04.638 : NewPassiveDataSocket(79.170.44.37,62300)
INFO [BaseSocket] 23 Sep 2012 15:40:04.638 : Connecting to 79.170.44.37:62300 with timeout 120000 ms
DEBUG [BaseSocket] 23 Sep 2012 15:40:04.638 : Successfully connected to 79.170.44.37:62300
DEBUG [FTPControlSocket] 23 Sep 2012 15:40:04.638 : Connected
DEBUG [FTPControlSocket] 23 Sep 2012 15:40:04.638 : ---> STOR public_html/sigma_test/201209041243.jpg
DEBUG [FTPControlSocket] 23 Sep 2012 15:40:04.731 : 150 Opening BINARY mode data connection for public_html/sigma_test/201209041243.jpg
DEBUG [FTPClient] 23 Sep 2012 15:40:04.731 : Closing source stream
DEBUG [FTPClient] 23 Sep 2012 15:40:04.731 : Transferred 45078 bytes to remote host
DEBUG [FTPControlSocket] 23 Sep 2012 15:40:05.823 : 226 Transfer complete
DEBUG [FTPConnection] 23 Sep 2012 15:40:05.823 : Closing connection (instance=12)
DEBUG [FTPFileFactory] 23 Sep 2012 15:40:05.823 : Defaulting to Unix parsing
DEBUG [FTPControlSocket] 23 Sep 2012 15:40:05.823 : ---> QUIT
DEBUG [FTPControlSocket] 23 Sep 2012 15:40:05.870 : 221 Goodbye.

All transfers appear to be identical. The example above happens to be one that corrupted the jpeg image but others are just the same.

My VB.Net code is very simple:

            Dim ftp1 As New FTPConnection

            ftp1.ServerAddress = txtFTPserver.Text

            ftp1.UserName = txtFTPusername.Text
            ftp1.Password = txtFTPpassword.Text
            ftp1.Connect()

            ftp1.UploadFile(sLocalPath, sServerPath)

            ftp1.Close()

Any ideas much appreciated.

Paul.

Answer 4

Probably the best thing to do now is to try Filezilla or another client to see if you experience the same problem.

Answer 5

Try setting the TransferType property to FTPTransferType.BINARY.

- Hans (EnterpriseDT)

Answer 6

Try setting the TransferType property to FTPTransferType.BINARY.

- Hans (EnterpriseDT)

Transfer type is already BINARY. I do not get any corruption with FileZilla.

Answer 7

So it is. The log says that 45,078 bytes were transferred. Is the size of the file? If so, try downloading the corrupted file from the server using FileZilla and comparing it with the original. You can use the "fc /B file1 file2" command to do this if you're on Windows.

Also, in your first message you wrote "Sometimes reloading the image from the server clears the corruption". Do you mean reloading it in the browser cleared the corruption? If so, that would indicate a problem elsewhere in the process.

If possible, you could send us a test app, the test files, and give us a test account on your server so that we can investigate it ourselves.

- Hans (EnterpriseDT)

Answer 8

Thank you for your continued support. I have been looking at the corrupted files in a HEX editor. The corrupted area is filled with 0s (zeros) and always seems to be 8192 bytes long. The start location varies but is always on a "round number" in HEX (what I might call a "page boundary") such as &H8000, &HC000 or &HE000. There is then a "footer" area in the file which is OK. The total number of bytes is always correct. So in summary, the last 8192 bytes of picture information is replaced with zeros but is followed by an area of correct information near the end of the file.

I'll post more info soon ... late for work !!

Answer 9

It's so strange. This code is over 10 years old and is in use in thousands - probably tens of thousands - of applications around the world. You'd think someone else would've reported an error of this nature before now.

What server are you using? Any chance of getting a test account on it? I'd love to see if happening myself.

- Hans (EnterpriseDT)

Answer 10

It's so strange. This code is over 10 years old and is in use in thousands - probably tens of thousands - of applications around the world. You'd think someone else would've reported an error of this nature before now.

What server are you using? Any chance of getting a test account on it? I'd love to see if happening myself.

- Hans (EnterpriseDT)

I will try to organise that for you. Give me 24 hours ...

Thanks for your help.