Our Products:   CompleteFTP  edtFTPnet/Free  edtFTPnet/PRO  edtFTPj/Free  edtFTPj/PRO
0 votes
3.8k views
in .NET FTP by (220 points)
I've noticed a strange behavior in my File Transfer wrapper around the edtdtp library. If I'm doing a binary transfer, the BytesTransferred event faithfully and reliably reports the current progress and at the end of the transfer the e.ByteCount property matches the size of the file being transferred.

However when using the same library doing an ASCII file transfer, the bytecount always stops about 5-6KB short of the actual size of the file. I've compared the actual files involved in the transfer (source and destination) and they are identical to the byte. It's just an issue of the reported byte count being off at the end of the transfer which in turn makes the user think that there was a problem with the transfer.

I am setting the TransferType property of the FTPClient class to either "ASCII" or "BINARY" depending on the type of file being transferred (either a zip file or an xml document).

Any suggestions on how to get the byte counts to match up?

Thanks,
Shawn.

3 Answers

0 votes
by (220 points)
I don't know if it's relevant. But after doing some additional tests with XML files of various sizes it appears that consistantly at 97.6% of the ASCII file transfer the edtftp stops sending BytesTransferred events.

I've played around with the TransferNotifyInterval trying values ranging from 512 to 8192 and the transfer progress reporting always stopped at 97.6%

My test files have varied in size from 16KB to 1.6 MB. All file transfers are occurring to an IIS FTP server on my development workstation.
0 votes
by (162k points)
When transferring ASCII files, it may never be accurate (depending on the FTP server), as there is a translation going on with line feeds.
0 votes
by
Hi,I met the same problem. But to be different,I use binary mode and I was transferring tif files.

It always stops at about 97.6%.That's weird!

Categories

...