Проблемы с System.Net.FtpClient при openwrite

Я видел десятки примеров устранения этой проблемы с помощью библиотеки, указанной в заголовке. Типичный пример, который ДОЛЖЕН работать, который я вижу:

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

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

Когда я выполняю этот код, я получаю ошибку длины имени в журнале ftpTrace. Когда я использую только путь назначения, я получаю ошибку тайм-аута. Я отправляю на мэйнфрейм MVS OS. Я могу подключиться и войти в систему нормально. возможность отправлять команды сайта через метод ftpclient.execute. Я попытался из любопытства отправить команду put через метод execute и получил неизвестную команду для put. У кого-нибудь тоже есть эта проблема?

Также соединение работает нормально, так как я вручную отправил файл через командную строку ftp и был успешным.

Некоторая справочная информация: метод OpenWrite библиотеки отправляет команду STOR, используя отправленный путь, и по умолчанию будет использоваться двоичный тип.


.net c# ftp mvs
person ggiaquin16    schedule 12.12.2016    source источник
comment
при использовании FTP, возможно, вам нужно использовать команды Change Dir, чтобы длинные имена файлов или имена путей не влияли на функциональность, которую я бы проверил в первую очередь .._ 1_ посмотрите, поможет ли это   -  person MethodMan    schedule 12.12.2016
comment
@MethodMan Path.GetFileName (localFile) в основном делает то, что вы описали. Он берет полный локальный путь и получает только имя файла.   -  person ggiaquin16    schedule 13.12.2016

Ответы (1)


arrow_upward
1
arrow_downward

Убедитесь, что вы настроили свою библиотеку FTP для использования активного режима (или включите пассивный режим FTP в вашем брандмауэре и мэйнфрейме)

Длинный ответ: протокол FTP использует два соединения: одно командное соединение от клиента к серверу и одно соединение для передачи данных, которое может подключаться либо от клиента к серверу (пассивный режим), либо от сервера к клиенту (активный режим).

Использование неправильного режима приведет к тому, что брандмауэр, не настроенный для этого режима, разорвет ваше соединение для передачи данных, что вызовет ошибку тайм-аута, с которой вы столкнулись.

Поскольку Windows ftp.exe поддерживает только активный режим, и вы не устанавливаете этот режим в своем коде, я предполагаю, что мэйнфрейм настроен для активного режима, в то время как ваша библиотека FTP по умолчанию работает в пассивном режиме. Пассивный режим сейчас очень распространен, поскольку активный режим плохо работает с маршрутизаторами NAT.

Проверьте, есть ли параметр конфигурации для изменения режима передачи, но не удивляйтесь, если библиотека поддерживает только пассивный режим.

Дополнительная информация:

person EventHorizon    schedule 15.12.2016
comment
Прости! Я должен был указать некоторые детали клиента библиотеки. У меня действительно был активный режим, и это было время ожидания. Когда у меня включен пассивный режим, я получаю отказ в соединении из-за ошибки сервера. Администратор сервера попросил меня сделать это в пассивном режиме, и я жду ответа от сетевой команды о портах. Библиотека поддерживает несколько типов как активных, так и пассивных. В настоящее время у меня установлен расширенный пассивный режим в соответствии с запросом администратора сервера. Это генерирует сообщение об отказе в соединении. - person ggiaquin16; 17.12.2016
comment
Сегодня я узнал о расширенном пассиве :-) Думаю, я слишком долго живу в мире IPv4. Похоже, вы скоро с этим разберетесь с помощью сетевых администраторов, удачи! - person EventHorizon; 18.12.2016