We use a piece of software called CrushFTP to run SFTP-related jobs. This runs on a Ubuntu 16.04 box. One of the servers we need to communicate with is an ancient OpenVMS box... I think it's OpenVMS 8.4? I'm not the VMS guy so I honestly don't know much about the target server, but hoping this may be a relatively simple thing to work around.
It looks like CrushFTP use a component called Maverick... and this here appears the problem.
If I use Ubuntu's command line sftp tool, I can connect to the server and run ls -lha. This returns a nice listing of files, for example:
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
If I run a get it downloads the files just fine... so in general, the SFTP server on OpenVMS seems to be working fine, and Ubuntu's native client is able to communicate with it just fine...
However, when we start trying to communicate with it using CrushFTP, things start to become a bit of an issue. Directories are OK, but files appear to have a trailing * in each filename, so for example, the above listing would be presented as:
SSH2.DIR;1
FILENAME1.EXT;3*
FILENAME2.EXT;3*
FILENAME3.EXT;2*
FILENAME4.EXT;3*
FILENAME5.EXT;3*
FILENAME6.EXT;3*
When we try to then copy the files to a local location, we receive the following error (which appears to be from this Maverick component):
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
It may be a red-herring, but the * seems to be the only real difference in the filenames. We have tested by creating files named for example FILENAME.EXT;3 and transferred them around with no issues. We've also been provided with a way to actually strip the version number ;3 from the target filename.. but it appears that that * in the source filename causes an issue. We can strip the * all we like, b
This trailing * does not cause a problem with non-OpenVMS servers so I'm almost certain it's something to do with the way the OpenVMS directories are being read, but I can't seem to pinpoint what or how we get around it.
Does anyone have any experience of OpenVMS SFTP servers, or even better CrushFTP and/or this Maverick component?
Thanks!
Update
I've been working with our VMS guy and I think we've finally established it's a permissions issue. For some reason, even though other native clients are fine, the CrushFTP client doesn't like the execute permission.
I managed to use FileZilla to create a new file and noted that it had -rw-r----- set by default. This was fine with CrushFTP.
Setting the permissions of another file to -rw-r----- also worked.
I think we're winning now! :)
