User (Old forums)MemberMay 13, 2008 at 6:10 pmPost count: 23064
While evaluating the latest version of the FTP libary for .NET I came accross the following behaviour that can be simulated by following the steps down below. Please let me know if there’s a fix available for this issue –
Problem: Very small files (1 – 2 charactes, or 4 bytes – for instance) are randomly downloaded empty, w/o errors being generated. The higher the connection speed to the FTP server, the higher the occurence rate. For an FTP server part of the LAN – we get about 15% of the files empty
How to reproduce the behaviour: (1) use a source FTP server with a high connection speed [I used FileZilla on a LAN server because I wanted to test implicit SSL]; (2) Have available on the FTP server several very small files, say 4 bytes each – we’ll attempt to download them in a single session [I used 100 text files, each having just 2 characters as the body of the file] (3) download all these files locally, one at a time, by name – as part of the same session. You’ll end up with about 15% of the files which are empty (size=0), and no errors raised on either end (server, or client).
Here’s the code that I used to simulate the behaviour. Thanks for your help —
static void Main(string args)
FtpClient ftpSession = new FtpClient();
int hostport = 990;
“your FTPS Server IP address”, hostport, AuthenticationMethod.Tls, VerificationFlags.None, null);
“your user name”, “your password”);
FtpItemInfoList items = ftpSession.GetFolderContents();
foreach (FtpItemInfo item in items)
if (item.Type == FtpItemType.File)
string dnloadRemoteName = item.Name + “.dload”;
string dnloadLocalName = “c:\\temp\\” + dnloadRemoteName;
AbstractFile localFile = new DiskFile(dnloadLocalName);
if (localFile.Size > 0)
localFile.Name = localFile.Name +
static void ftpSession_CertificateReceived(object sender, CertificateReceivedEventArgs e)
Applies to Xceed FTP for .NET. Imported from legacy forums. Posted by Leonard (had 5565 views)Xceed SupportMemberMay 14, 2008 at 12:13 pmPost count: 5658
Just to notify you that we are investigating the issue. We were able to reproduce the problem. As soon as we have new development, we will notify you.
Applies to Xceed FTP for .NET. Imported from legacy forums. Posted by CharlesB (had 1114 views)User (Old forums)MemberMay 14, 2008 at 12:57 pmPost count: 23064
Great, thanks Charles –
Applies to Xceed FTP for .NET. Imported from legacy forums. Posted by Leonard (had 1404 views)User (Old forums)MemberMay 20, 2008 at 1:03 pmPost count: 23064
I was wondering if there’s any chance to get this issue addressed within the next couple of days?
This will help us decide whether to wait for the fix, or look elsewhere
Thanks very much,
Applies to Xceed FTP for .NET. Imported from legacy forums. Posted by Leonard (had 1063 views)Xceed SupportMemberMay 22, 2008 at 8:33 amPost count: 5658
We are currently investigating the issue. We’ll keep you informed as soon as we have more information.
Thanks for your comments,
Applies to Xceed FTP for .NET. Imported from legacy forums. Posted by Chris [Xceed] (had 1311 views)User (Old forums)MemberMay 26, 2008 at 11:24 amPost count: 23064
We have been able to identify the problem in the Secure layer of the Ftp component, but that at this time, we will not be able to correct it rapidly. It is a problem that is deeply located in the core of the library, and is due to the fact that the library is asynchronous/multithreaded underneath, and very small files (<= 8k) cause a race condition. Correcting this will require to make important changes to the way the library works. This requires a thoughtful evaluation and an important investment of time and resources.
The only workaround available at this time is to NOT use a secure connection when uploading small files.
We will post back here when we have resolved the issue.
Applies to Xceed FTP for .NET. Imported from legacy forums. Posted by André (had 1022 views)User (Old forums)MemberJune 16, 2008 at 12:30 pmPost count: 23064
Is there any time frame to this issue? This issue has caused us countless support calls with users of systems which use the FTP component and we have to resolve this as soon as possible. I appreciate the issues around development time, but frankly an FTP component that does not download files reliably is fundamentally not fit for purpose. We are using version 3.7.8125.15060 of the Xceed.Ftp component. Is there a work around in the meantime?
Applies to Xceed FTP for .NET. Imported from legacy forums. Posted by basik (had 1207 views)User (Old forums)MemberJune 17, 2008 at 3:26 pmPost count: 23064
We have other important releases around the corner for other products, and resources are not available to address this right now.
Do not forget that this problem is for rather small files (<= 8k), and that is it only when using SSL/TLS. So there are a couple of workarounds, which are not to use the secure connection for those files, or zip those files and send them as a unique file.
Applies to Xceed FTP for .NET. Imported from legacy forums. Posted by André (had 774 views)User (Old forums)MemberJune 18, 2008 at 6:28 amPost count: 23064
Thank you for your response. Unfortunately, in this case SSL/TLS is mandatory and files are provided by a third party and there is no way to group, zip files etc. Although the incidences of files less than 8K is low, when it does happen, this issue is significant. I have had some measure of success with implementing a retry list of failed FTP downloads. Although there are still instances where the underlying FTP threads appear to hang and then eventually timeout. The biggest problem is that failed threads sometimes keep a handle to the zero byte file preventing a retry overwriting that file. I have tried calling Abort() on the ftpclient but this does not appear to release the lock.
Is there anyway to ensure that the underlying threads are killed off before retrying a set of downloads? That would probably be a sufficient work around for us. Thanks for your help here.
Applies to Xceed FTP for .NET. Imported from legacy forums. Posted by basik (had 1099 views)User (Old forums)MemberJune 20, 2008 at 2:43 pmPost count: 23064
Unfortunately, it is not possible to kill those underlying thread directly. I think the only solution here would be to dispose of the ftpclient and wait for the port to be closed by the OS on the local side, and possibly by the server on the ftp side, so that the handle on the file is released.
Applies to Xceed FTP for .NET. Imported from legacy forums. Posted by André (had 693 views)User (Old forums)MemberJune 23, 2008 at 11:40 amPost count: 23064
Thanks for your help. We’ll wait for the fix and just implement a retry in the meantime.
Applies to Xceed FTP for .NET. Imported from legacy forums. Posted by basik (had 2940 views)User (Old forums)MemberSeptember 8, 2011 at 2:08 pmPost count: 23064
- You must be logged in to reply to this topic.