This project is read-only.

Two critical data communication bugs


Hi, I use System.Net.FtpClient assembly to download/upload a bunch of files to FTP from single thread (all timeout are default). I shortly reached the server connection limit (20 pcs) if EnableThreadSafeDataConnections=true. I investigated the assembly code and found that OpenRead/OpenWrite don't close duplicated connections and they alive for timeout (see ftpClient variable):
    public virtual Stream OpenWrite(string path, FtpDataType type)
      FtpDataStream ftpDataStream = (FtpDataStream) null;
      lock (this.m_lock)
        System.Net.FtpClient.FtpClient ftpClient;
        if (this.m_threadSafeDataChannels)
          ftpClient = this.CloneConnection();
          ftpClient = this;
        long fileSize = ftpClient.GetFileSize(path);
        ftpDataStream = ftpClient.OpenDataStream(string.Format("STOR {0}", (object) path.GetFtpPath()), 0L);
        if (fileSize > 0L)
          if (ftpDataStream != null)
      return (Stream) ftpDataStream;
So, I set EnableThreadSafeDataConnections=false and .... got strange errors. My investigation shows that the answers from ftp server mixed: ExistDirectory/CreateDirectory sometimes throw error "550 Could not get file size", TYPE I doesn't apply for binary uploading (I got corrupted binary files), ... The problem was with double answer for data transfer commands (for example STOR/RETR): "150 Ok to send data" + "226 Transfer complete". Your code doesn't expect second answer! So, next commands read previous answers! I expect the bug with any other FTP commands where data connections used.

Could you please fix both critical bugs?


geotarget wrote Jul 28 at 9:36 AM

What an idiot you are. Read the big notice on the homepage. Use FluentFTP. All these issues have already been fixed.

ww8987 wrote Jul 28 at 11:53 AM

The idiot is the person who say that word to an another unknown person.
Thanks for the redirect. Google can't match FluentFTP and System.Net.FtpClient...