1

I have seen dozens of examples when trouble shooting this issue using the library in the title. The common example I am seeing that SHOULD work is:

        string destinationPath = PathInfo.FileNameConvention;
        using (FileStream fileStream = File.OpenRead(sourcePath))
        {

            using (Stream ftpStream = FTPClient.OpenWrite(string.Format("'{0}'", destinationPath), FtpDataType.ASCII))
            {
                fileStream.CopyTo(ftpStream);
            }
        }

When I do this code, I get a name length error on the ftpTrace log. When I use only the destination path, I get a time out error. I am sending to a mainframe MVS OS. I can connect in and log in just fine. able to submit site commands via the ftpclient.execute method. I tried, out of curiosity, to submit a put command via the execute method as well and got unknown command for put. Anyone having this issue too?

Also the connection works fine as I have manually submitted a file via cmd prompt ftp and was successful.

Some background information, the OpenWrite method of the library sends a STOR command using the path sent in and will default to binary type.

ggiaquin16
  • 165
  • 1
  • 15
  • when doing FTP perhaps you need to use the Change Dir commands so that long File names or Path names do not affect the functionality I would check into that first..`Meaning ChangeDir, then pass the filename not the full Path` see if that helps – MethodMan Dec 12 '16 at 15:57
  • @MethodMan Path.GetFileName(localFile) basically does as you described. It takes the full local path and gets just the file name. – ggiaquin16 Dec 12 '16 at 21:35

1 Answers1

1

Check that you have configured your FTP library to use active mode (or enable FTP passive mode in your firewall and mainframe)

Long answer: The FTP protocol utilizes two connections, one command connection from the client to server, and one data connection which can connect either from client to server (passive mode) or server to client (active mode).

Using the incorrect mode will cause a firewall not configured for that mode to drop your data connection, which will cause the timeout error you're experiencing.

Since Windows ftp.exe only supports active mode, and you're not setting the mode in your code, I'm guessing the mainframe is configured for active mode while your FTP library defaults to passive mode. Passive mode is very common now since active mode doesn't work well with NAT-ing routers.

Check if there's a configuration setting to change the transfer mode, but don't be surprised if the library only supports passive mode.

More information:

Community
  • 1
  • 1
EventHorizon
  • 2,916
  • 22
  • 30
  • Sorry! I should have specified some library client details. I actually had active mode active, and that was timing out. When I have passive mode on, it gives me a connection refused by server error. The server admin requested for me to do it in passive mode and I am waiting to hear back from the networking team about the ports. The library supports several types of both active and passive. Currently I have it set to extended passive as per server admin request. This is generating that connection refused message. – ggiaquin16 Dec 16 '16 at 22:07
  • Today I learned about "extended passive" :-) I've been living in a IPv4-world too long I guess. Sounds like you'll sort it out soon with some help from the network admins, good luck! – EventHorizon Dec 18 '16 at 12:57