Мы используем программное обеспечение CrushFTP для выполнения заданий, связанных с SFTP. Это работает в системе Ubuntu 16.04. Один из серверов, с которым нам нужно общаться, - это старый ящик OpenVMS ... Думаю, это OpenVMS 8.4? Я не специалист по VMS, поэтому я, честно говоря, не очень много знаю о целевом сервере, но надеюсь, что это относительно простая вещь, которую можно обойти.

Похоже, CrushFTP использует компонент под названием Maverick ... и здесь возникает проблема.

Если я использую командную строку Ubuntu sftp инструмент, я могу подключиться к серверу и запустить ls -lha. Это возвращает хороший список файлов, например:

Connected to hostname.domain.tld.
sftp> ls -lha
drwx------    0 16777291 256          512B Oct  8  2018 SSH2.DIR;1
-rwxr-x---    0 16777291 256            4B Oct 19 13:26 FILENAME1.EXT;3
-rwxr-x---    0 16777291 256          284B Oct 19 13:26 FILENAME2.EXT;3
-rwxr-x---    0 16777291 256          1.2M Oct 19 13:26 FILENAME3.EXT;2
-rwxr-x---    0 16777291 256            4B Oct 19 13:26 FILENAME4.EXT;3
-rwxr-x---    0 16777291 256          288B Oct 19 13:26 FILENAME5.EXT;3
-rwxr-x---    0 16777291 256          1.5M Oct 19 13:26 FILENAME6.EXT;3

Если я запустил получить он загружает файлы нормально ... так что в целом SFTP-сервер в OpenVMS, похоже, работает нормально, и собственный клиент Ubuntu может нормально с ним общаться ...

Однако, когда мы начинаем пытаться общаться с ним с помощью CrushFTP, все начинает становиться проблемой. Каталоги в порядке, но файлы кажутся завершающимися * в каждом имени файла, поэтому, например, приведенный выше список будет представлен как:

SSH2.DIR;1
FILENAME1.EXT;3*
FILENAME2.EXT;3*
FILENAME3.EXT;2*
FILENAME4.EXT;3*
FILENAME5.EXT;3*
FILENAME6.EXT;3*

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

attempting to copy (1) SFTP://sftptest:****@hostname.domain.tld:22/dir/dir1/FILENAME2.EXT;3* to file://local/directory/structure/FILENAME2.EXT;3*
com.maverick.sftp.SftpStatusException: No such file: syserr: no such file or directory, or no privilege for attempted operation, file: /dir/dir1/FILENAME2.EXT;3*
com.maverick.sftp.SftpSubsystemChannel.extractAttributes:2275
com.maverick.sftp.SftpSubsystemChannel.getAttributes:2257
com.maverick.sftp.SftpSubsystemChannel.getAttributes:2209
com.sshtools.sftp.SftpClient.getInputStream:1604
com.crushftp.client.SFTPClient.download3:574
com.crushftp.client.GenericClient.download2:422
com.crushftp.client.GenericClient.download:264

Это может быть отвлекающий маневр, но * кажется единственной реальной разницей в именах файлов. Мы протестировали, создав файлы с именами, например FILENAME.EXT; 3 и без проблем передал их. Нам также предоставили способ фактически удалить номер версии ; 3 из имени файла назначения .. но похоже, что * в имени файла источника вызывает проблему. Мы можем раздеть * все, что нам нравится, b

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

Есть ли у кого-нибудь опыт работы с серверами OpenVMS SFTP или даже лучше CrushFTP и / или этим компонентом Maverick?

Спасибо!

Обновить

Я работал с нашим парнем по VMS, и я думаю, что мы наконец установили, что это проблема с разрешениями. По какой-то причине, даже если другие собственные клиенты в порядке, клиент CrushFTP не любит разрешение на выполнение.

Мне удалось использовать FileZilla для создания нового файла, и я заметил, что по умолчанию для него установлено -rw-r -----. Это было нормально с CrushFTP.

Установка разрешений для другого файла на -rw-r ----- также работала.

Думаю, сейчас мы выигрываем! :)