Мы используем часть программного обеспечения под названием CrushFTP для выполнения заданий, связанных с SFTP. Это работает на Ubuntu 16.04 box. Один из серверов, с которым нам нужно общаться, - это древний ящик 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

Если я запускаю get, он загружает файлы просто отлично... так что в целом 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 из целевого имени файла... но похоже, что это * в имени исходного файла вызывает проблему. Мы можем раздеть * все, что нам нравится, б

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

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

Спасибо!

Обновить

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

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

Установка прав доступа к другому файлу -rw-r----- также работала.

Я думаю, что мы выигрываем сейчас!:)