Fetch Softworks

SFTP Problems w/VMS (MultiNet) (5 posts)

• Started 18 years ago by mfleming
• Latest reply 18 years ago from mfleming

• mfleming Member

  I'm running Fetch 5.0 on 10.3.9 and I'm having problems with text file transfers in both directions with OpenVMS systems using MultiNet's tcp/ip stack and ssh.

  When I do a get, I get the following error:

  SSH2_FXP_OPEN /sys$sysroot/000000/sysmgr/change-ip.com
  SSH2_FXP_FSTAT 15
  SSH2_FX_FAILURE 15
  Unsuccessful transfer of change-ip.com (0 bytes, 0 bytes/sec, 0:00 elapsed) stopped at 5/24/05 12:29:09 PM
  ftp_retrieve: 24104 (state == RGET_RETRIEVING)

  The error message is not human readable but what I suspect is that there is a file size mismatch with what Fetch was told versus what it actually found. The SSH on VMS estimates the file size because it converts the file to stream_lf on the fly. So, I'm not sure what the RFC's say but if Fetch could be made to not fail on unexpected EOF, that would be great. (The command line scp/sftp reports the error but transfers the file anyway.) I've complained to Process Software (makers of MultiNet) but they don't seem real interested in developing a solution on their end.

  The second problem is for the other direction, text files sent to VMS do not transfer properly. I've selected TEXT as the format/mode but the line terminators are not correct. On VMS, the resulting end of line is a plain CR (0D); looking at existing text files on VMS, it looks like it should be LF (0A). What am I missing to get this to work?

  Thanks for your help.

  Michael

  Posted 18 years ago #

• Jim Matthews Administrator

  I'd be interested in more information about the get problem. You can enabled Fetch 5's debug menu by typing Command-Option-Shift-Control-D. Then choose "SFTP log" from the Logging menu in the Debug menu. Then connect, try to download a file, and send the contents of Fetch Transcript to bugs at fetchsoftworks.com.

  As for the text file upload issue, by default Fetch does not change text file line endings for SFTP uploads. So if the file had CR line endings on the Mac, that's what Fetch will send. You could experiment with changing the line ending on the Mac (with BBEdit, or some other text editor) before uploading.

  There's also a secret preference to tell Fetch to set a specific line ending for SFTP text uploads. Let me know if you want to try that.

  Thanks,

  Jim Matthews
  Fetch Softworks

  Posted 18 years ago #

• mfleming Member

  as per your request I have sent the transcript to the bugs email address.

  I am not the least bit interested in editting every text file and changing its line terminators before I send it to the VMS system. Please.

  However, I would be very interested in using a preference to set the line terminator as needed. It is unfortunate that setting format/mode to TEXT doesn't take care of that for the user.

  Posted 18 years ago #

• Jim Matthews Administrator

  Unfortunately SFTP (unlike FTP) does not have a standard for line endings, so Fetch either has to guess the line ending to use, ask the user, or leave the line endings alone. By default Fetch leaves the line endings alone. If you run Terminal and type

  defaults write com.fetchsoftworks.Fetch SFTPUploadTextEOLStyle -int 1

  it will convert line endings to CR (carriage return), the Mac OS 9 standard.

  defaults write com.fetchsoftworks.Fetch SFTPUploadTextEOLStyle -int 2

  tells Fetch to use LF (linefeed), the Mac OS X and UNIX standard.

  defaults write com.fetchsoftworks.Fetch SFTPUploadTextEOLStyle -int 3

  tells Fetch to use CRLF (carriage return followed by linefeed), the DOS/Windows standard

  defaults write com.fetchsoftworks.Fetch SFTPUploadTextEOLStyle -int 0

  tells Fetch to leave the line endings alone (the default behavior).

  Let me know if that does not fix the problem.

  Thanks,

  Jim Matthews
  Fetch Softworks

  Posted 18 years ago #

• mfleming Member

  Yep, that worked. However, as I've dug into this I think I just happened to choose a bad file to test. I'm trying to remember how I created this file but since the creation date is December 2003, it ain't going to happen. It could be a MacOS9 leftover. The point being that normal MacOSX text files transfer just fine, it's just this odd-ball that has been giving me fits.

  So, my apologies for stirring things up over an outlier; nonetheless, these hidden options could come in handy for someone who might have a whole mess of old MacOS9 text files lying around that they need to xfer to VMS.

  Thanks for all your help.

  Posted 18 years ago #