4+ MB zip gets inflated to 8+ Mb Corrupt File

Question

I'm not getting any errors. It's just, after I upload a file, the file is a lot bigger and is no longer valid. The file in question is a zip file, and I'm using binary. I seem to be able to transfer small text files in ASCII okay. Anyone got any ideas?

Answer 1

Are you sure you are using binary? This normally happens if you upload a zip file as ASCII.

Post a small section of the log file set to Debug level.

Answer 2

Thanks for your response. Here's the log. Yeah, it never mentions actually taking the binary setting, even though I set .TransferType = EnterpriseDT.Net.Ftp.FTPTransferType.BINARY.

DEBUG [HostNameResolver] 20 Jul 2007 17:04:31.174 : ftp.drivehq.com resolved to 66.220.9.50
DEBUG [FTPClient] 20 Jul 2007 17:04:31.174 : Connecting to 66.220.9.50:21
DEBUG [FTPControlSocket] 20 Jul 2007 17:04:31.346 : 220 Welcome to the most popular FTP hosting service! Save on hardware, software, hosting and admin. Share files/folders with read-write permission. Visit http://www.drivehq.com/ftp/
DEBUG [FTPControlSocket] 20 Jul 2007 17:04:33.768 : ---> USER cheapbooks
DEBUG [FTPControlSocket] 20 Jul 2007 17:04:33.862 : 331 User name ok, need password.
DEBUG [FTPControlSocket] 20 Jul 2007 17:04:33.862 : ---> PASS ********
DEBUG [FTPControlSocket] 20 Jul 2007 17:04:33.956 : 230 User successfully logged on.
DEBUG [FTPControlSocket] 20 Jul 2007 17:05:04.223 : ---> PASV
DEBUG [FTPControlSocket] 20 Jul 2007 17:05:04.317 : 227 Entering Passive Mode (66,220,9,50,19,53).
DEBUG [FTPControlSocket] 20 Jul 2007 17:05:04.317 : Server supplied address=66.220.9.50
DEBUG [FTPControlSocket] 20 Jul 2007 17:05:04.317 : Server supplied port=4917
DEBUG [FTPControlSocket] 20 Jul 2007 17:05:04.317 : Substituting server supplied IP (66.220.9.50) with remote host IP (66.220.9.50)
DEBUG [FTPControlSocket] 20 Jul 2007 17:05:04.317 : NewPassiveDataSocket(66.220.9.50,4917)
DEBUG [FTPControlSocket] 20 Jul 2007 17:05:04.411 : ---> STOR CheapBooks.zip
DEBUG [FTPControlSocket] 20 Jul 2007 17:05:04.536 : 150 Connection accepted
DEBUG [FTPControlSocket] 20 Jul 2007 17:06:28.071 :
DEBUG [FTPControlSocket] 20 Jul 2007 17:06:41.400 : ---> QUIT
DEBUG [FTPControlSocket] 20 Jul 2007 17:06:41.400 : 226 Transfer complete

Thanks again, Dale.

Answer 3

You got me pointed in the right direction :)

That is, that the transfer type setting just wasn't taking BINARY. So, I figured if this is not happening to anyone else, and it's just me, I must be doing something odd.

I looked back at the example that comes with the source, and I noticed there's both an FTPConnection and an FTPClient object (and examples). I was using the FTPConnection object, working through the settings down to the .uploadfile method, and that just doesn't seem to be able do binary. As soon as I switched to using the FTPClient object; working my way down to the .put method, it worked like a charm!

Thanks so much. I am now able to automate my delivery of zip files. If anyone needs a crappy unsupported .NET console implementation of this awesome library, so you can send files passively through a firewall from a batch file, let me know.

Dale

Answer 4

We'll check this out as FTPConnection (which is the preferred class to use) should work fine with binary transfers.

Answer 5

I had this same issue with the exception that my files are not doubled in size. Original size 2,812,970 and uploaded size 5,163,994.

I also changed to use FTPClient away from FTPConnection and it worked fine.

Answer 6

These transfers work fine on our machines. Would you be able to create a little program that illustrates the problem and e-mail it to us at support@enterprisedt?

- Hans (EnterpriseDT)

Answer 7

Hi

I have the same problem. I have used the 1.2.0 for ages and it has worked perfectly. Now I upgraded to the (free edtFTPnet) 1.2.5 and all the sudden my uploaded files (mp3 and images) doubles in size and gets totally corrupted.

I get no errors. What is causing this? I am using FTPConnection.

And yes. I am using BINARY.

Please help me :)


EDIT: I tried with your 4.2.0 PRO demo version and it works like a charm. So there must be some kind of error in the 1.2.5 free version?

EDIT2: I investigated further.. free version 1.2.4 works aswell. This symptom only resides in 1.2.5. I really like the uploads speed in it so it would be awesome if you could locate the bug and fix it :)

Answer 8

We'll take a look. If possible can you post the log file for a corrupted transfer?

Actually if you can email a small demo program together with a small test file (zip them all up) to support at enterprisedt dot com we'll test it out.

Answer 9

How do I create a log file with the free edition?

Answer 10

Please see here. These instructions are for edtFTPnet/PRO, but it's the same with the free version except that you substitute FTPConnection where it says SecureFTPConnection.

- Hans (EnterpriseDT)