Hello,
Tried using AT's SFTP to transfer files between Windows 7 and OpenVMS (Multinet V5.3 IP stack).
Transfer to the host goes just fine.
Transfer from the host returns this error:
Error:
Getting remote file size failed.
Invalid handle. Handle not found.
Click OK and it creates an empty file on the Windows PC.
Odd that it should report a problem getting the file size because it shows the size in the directory pane and when repeating the transfer attempt, it presents a dialog showing that it knows the server file is 990 bytes as shown in the directory pane.
Note sure what to make of that.
Any ideas?
The same call that gets the file size also gets the file modification time. If either fails, it complains it can't get the file size. To make things a bit clearer in regard to what we're dealing with, I need to split those messages apart first, then address the problem underneath.
Would you be willing to try a test version?
and BTW, what version are you using?
Sure.
I may have to go through my desktop engineering group, however.
To be more specific:
What version of Absolute
and also
What version of OpenVMS?
Ok. Tried another system. Got different error...
The first one we're already looking at:
$ multinet show/version
Process Software MultiNet V5.3 Rev A-X, VAX 7000-760, OpenVMS VAX V6.2
I also have an Alpha running a newer version and a non-third-party IP stack:
$ tcpip show version
HP TCP/IP Services for OpenVMS Alpha Version V5.6
on an AlphaServer ES45 Model 2B running OpenVMS V8.3
In this case, transfer works in neither direction.
From the server to the PC does nothing at all.
From the PC to the server returns a message box with this text:
Error:
Setting remote modify time failed.
Operation failed: syserr: file currently locked by another user
This usually means the program already has the output file open for exclusive access, but attempted another operation on a different channel.
AT is V9.82
I have a feeling both issues are related to getting and setting the modify time on the file.
Version 10.12 already addresses setting the modify time when sending the file to the host. It still tries to set the modify time, but ignores the error if it can't.
Sounds like a similar fix needs to be made when getting a file as well.
Can you try version 10.12 and see if it fixes at least half this problem?
Brian
I don't have privileges to install software on this PC. We'd need to find a work-around for that.
Don't know how helpful this would be, but it's usually enough to set the file creation date to a desired value and let the system set the modified date or DOS's old "archive bit". This enables incremental backups on the server.
Setting the creation date may be an option in the o.s. call to create the file.
Don't really know if this is worth the effort. I was just looking for an SFTP client that the user already has rather than requesting something like FileZilla from the desktop group.
I've got an update for you to try. This version separates the actions of getting date and size so we at least know more precisely where the error is occurring.
Let me know if you can somehow obtain permission to install this update
http://www.celestialsoftware.net/telnet/AbsoluteTelnet10.15RC4.exe
Brian
Have you had any chance to try testing this?
The RC4 version likely doesn't solve the problem, but will give us better messages to lead us to a final solution.
Brian
Here's the (hopefully final) beta for 10.15, which includes code to address this file transfer issue, but I'd like to get some feedback on whether it helped!
http://www.celestialsoftware.net/telnet/AbsoluteTelnet10.15RC9.exe
Regards,
Brian
Here's the final update for 10.15 (final release)
http://www.celestialsoftware.net/telnet/AbsoluteTelnet10.15.exe
Brian
