Hello,

I have working code that uploads files to an FTP server using FTPeek 1.61 and FM Pro Advanced 10. It also works with FM Pro Advanced 11.

I'd like to switch to using an SFTP server, so I added the necessary lines to get the public key and connect to the sftp server.

Unfortunately, the FTPeek_UploadFile command that works fine with the FTP server isn't working with the SFTP server.

When called, the progress bar appears and stays stuck at 0%. The CPU load for Filemaker goes to 99%. A check of the SFTP servers shows that the file has been created, but is 0 bytes in length, with a date of Dec 31st, 69.

From OS X's terminal I'm able to sftp into the same server and 'put' a file into the account.

Although the upload code is unchanged from what worked/works with the FTP server, I thought perhaps that was just luck (and I'd done something wrong).

So, I tried the FTPeek Sample Client. As with my code, the sample client can log into the ftptoday sftp server, but it wedges when trying to upload a file. Same symptoms; CPU load for FM goes to 99% and the upload never completes. A zero length file with the correct name is created in the sftp account, with the data Dec 31st, 69.

Both the FTP server & SFTP server are hosted by ftptoday.com, and I don't have insight into their configuration, nor who's SFTP/FTP they use, nor what version it is.

But, I do have a test account that 360works can use, and I've sent an email to what I thought was the right address at 360works. Either it wasn't the right address, or it is the right address and it's still in the queue to be looked at & investigated.

Not knowing which of those it is, I thought I'd submit a question to the forum, as this might have a better chance of the right folks at 360works seeing my plea for help.

Thanks!

Hello, we received your email and are looking into this issue.

I too am having this issue - I've a process to upload to 7 SFTP servers, and one is stalling the upload during the FTPeek_Upload step. If you use a command line or UI sftp browser you can see 0 byte files of the intended upload file but the filenames prefixed with '.in.' to make them invisible.

 

Was this issue quietly resolved to anyone's satisfaction - if so do let me know.

 

(I've also sent a mail directly to 360 on this - I'm just covering the bases checking here with this exact same issue)

 

Thanks for any advice.

I have discovered one thing about the errant SFTP server that might be causing the lockup. I've 7 servers and only one is causing the lock. Similarly if I try it from command line, it is the only server that *before the password prompt* asks for access to the id_dsa key of MY client

 

i.e. the server is trying to check MY identity possibly for auto-authentication by token

 

If you cancel this request and login with the password as normal the command line login works and you can upload normally. So it could be the plugin is just thrown into an unknown state by this response. Very much me guessing there. (And not truly understanding how SSH certificate checking *really* works)

I contacted [email protected] and they fixed me up with a working update! Thanks very much to 360works - great service and a great product. (The other plugins too I expect!)