As of 7.0.1754.3, XCALL FTPDLX has been officially dropped and all calls to it are redirected to FTP2. (FTPDLX was only available under Windows, required COM support, including that the DLL be registered, and hadn't been updated to support SFTP protocol / security refinements in ages. FTP2 on the other hand, runs on all platforms, requires no COM/registration, has kept up with the latest security/protocol patches, and offers a number of enhanced features.)

For more details, see the Release Notes for edits 1753 and 1754.

We thought that as of 1754.3, the two routines were sufficiently compatible to be interchangeable, but read on for an apparent crack in that edifice...

[From Stephen Funkhouser reposted here]...

I had to revert the laptop I installed 1752.3 on back to 6.5 because of SFTP issues. After digging into the issue in my environment I think the problem boils down to the depreciation of FTPDLX. We have been using FTPDLX for Window's A-Shell because the version of ashnet.dll was not new enough to support the XFTPF_RMVEXT flag. I had comments in our FTP code about that change and was waiting to update that to switch to FTP2 for that flag.

The issue I believe is that FTP2 status codes are not equivalent to FTPDLX status codes, and our logic testing for (status # 0) reporting error. From looking at the server the files the user reported errors for were successfully uploaded.

We're going to update all these laptops to 6.5.1726.0; which, has a new enough ashnet.dll to support the XFTPF_RMVEXT flag, and then modify our code to use FTP2.

1. Does this sound right
2. I'm in favor of the move to FTP2, but it seems like a quagmire if the status codes don't return the same as FTPDLX

Ugh. It appears that I overlooked that detail, i.e. that FTP2 returns status values > 0 to indicate success (typically # of files transferred), whereas FTPDLX returned 0 (but it didn't support multi-file transfers so there wasn't any particular need to return the file transfer count.)

Logically we could change the return status for FTP2 to be 0 for success in single-file transfers, but that might break someone else's code.

Probably the only completely backward compatible solution would be to create a wrapper for FTP2 when called as FTPDLX that maps status values > 0 back to 0. That doesn't sound too difficult, but obviously I'd rather add it to the latest 7.0 version (1757.3) rather than splice it back into 1754.3.

That makes sense

For what it's worth, I've posted a 7.0.1757.3 -el7 that I think fixes the FTP2 issue described above...

ash-7.0.1757.3-el7-upd.tz
ash70notes.txt

You should also get this update of libashnet...

libashnet.so.1.14.194-el7.tz

(Earlier versions may not work with this latest ashell due to some reorganization of routines shared between them.)

I found another FTP2 bug related to the XFTPF_RENAME, XFTPF_DEL and XFTPF_RMVEXT opcodes; the fix is in 1757.4 ...

ash-7.0.1757.4-el7-upd.tz
ash70notes.txt