SFTPPlus 3.6.0 Release
- ⬅ All articles
- 🗂 Categories
- 🔖 ftp (1)
- 🔖 infrastructure (3)
- 🔖 privacy (1)
- 🔖 compliance (1)
- 🔖 client-side (1)
- 🔖 general (84)
- 🔖 blog (6)
- 🔖 press (2)
- 🔖 australia (1)
- 🔖 client (17)
- 🔖 release (81)
- 🔖 article (14)
- 🔖 security (24)
- 🔖 server (19)
- 🗄 Archive
- 📌 2001 (3)
- 📌 2005 (1)
- 📌 2006 (1)
- 📌 2007 (1)
- 📌 2008 (1)
- 📌 2012 (1)
- 📌 2013 (3)
- 📌 2014 (13)
- 📌 2015 (20)
- 📌 2016 (23)
- 📌 2017 (14)
- 📌 2018 (38)
- 📌 2019 (17)
Fri 18 March 2016 | release security
We are pleased to announce the latest release of SFTPPlus, version 3.6.0.
Here is the list of the important new functionalities:
- The OpenSSL version used by SFTPPlus is advertised as part of the events generated when starting the SFTPPlus process, as well as in the Local Manager status page.
- Now you can configure the source port used by the FTP and FTPS services to initiate active data connections. [ftp][ftps]
- The matching rules for file dispatching are now applied to the full path, not only to the file name.
This release was focused on reducing the number of known defects and improving the quality of the product. Here is the list of the main defects fixed in this release:
- When a transfer requires multiple files to be transferred, they are now queued so that the files are transferred sequentially, one at a time. [#3131]
- When a location fails to start, it is no longer auto-started by a transfer. Now it needs to be manually started after the failure was investigated. All components/transfer trying to use a location which failed, will also have their operation failed. [#3176]
- Locations are now auto-started in the correct state, emitting an event and not leaving them in a 'restart-required' state. [#3176]
- The file transfer services secured by TLS/SSL and using a CRL will automatically stop/fail if the CRL can not be updated at runtime. In previous versions a warning was raised but the file transfer service continued to operate with a version of CRL which was previously loaded, resulting in an insecure operation. [security] [#3216]
- The files already present on the source location for a transfer are now filtered based on the transfer configuration and processed only after they are stable. [#3223]
- The file dispatcher event handler now no longer enters an infinite loop by handling its own events. [#3261]
- No internal server error is now produced when failing to remove the remote file after the file was successfully transferred on the local machine. [client] [#3283]
- Starting the Local Manager or the documentation pages from the Windows Start menu or using the command line using the admin-commands manager command, now successfully opens the default browser. [local-manager] [#3295]
These are just the highlights of this release. For more details, including the full list of changes, please see the full release notes.