Syncplify Server! v6.2.32 released

Importance of this update: [HOT-FIX]
What’s changed?
  • Fixed the gzip log rotator, it now correctly gzips log files upon rotation to save space, and doesn’t leave zombie files on disk
  • Slightly improved the logging of users’ PKI authentication phases

IMPORTANT NOTE: those who are running the “worker” system service under a different account (not System or LocalSystem) will need to re-configure the service to run under such account after upgrading from any version number <= 6.1.12)

Upgrading from v6.x.y is a simple and fairly automatic process: simply download the latest version from the official download page, and install it over the existing version, all of your settings and license will be kept.

If, instead, you’re upgrading from an older (v4/v5) version, you find the upgrade instructions in our knowledge base.

Thank you all for trusting our software with your secure file transfers!


Syncplify Server! v6.1.9 released

Importance of this update: NORMAL
Fixed
  • The Zip function in the scripting language now correctly supports Windows and Linux compatible encrypted zip archives
  • Several minor glitches in the UIs (SuperAdmin and Admin) have been fixed, if you experienced some issues with the UIs this is definitely an update you want to perform

Upgrading from v6.x.y is a simple and fairly automatic process: simply download the latest version from the official download page, and install it over the existing version, all of your settings and license will be kept.

If, instead, you’re upgrading from an older (v4/v5) version, you find the upgrade instructions in our knowledge base.

Thank you all for trusting our software with your secure file transfers!


Syncplify Server! v6.1.8 released

Importance of this update: MINOR
Fixed
  • Fixed behavior of ImportFile and ExportFile VFS methods in the scripting engine
New
  • Added HashFile function to the scripting engine to compute hash codes of local files
  • Added optional password parameter to the Zip function in the scripting engine: if not empty, the created zip archive will be encrypted
  • Added the possibility to edit the notes for each item in the Safe-List and Allow-List

Upgrading from v6.x.y is a simple and fairly automatic process: simply download the latest version from the official download page, and install it over the existing version, all of your settings and license will be kept.

If, instead, you’re upgrading from an older (v4/v5) version, you find the upgrade instructions in our knowledge base.

Thank you all for trusting our software with your secure file transfers!


WebClient! v2: downloading multiple files at once as a “zip” archive

Syncplify Server! v6 will include (depending on the software edition you run) WebClient! version 2. Aside from a brand new set of much more streamlined APIs and a much tighter integration between the two pieces of software, WebClient! v2 will also feature the ability to let users download multiple files and folders in one single “zip” archive, pretty much like some of the cloud storage apps out there do.

For safety and security reasons, though, administrators will be able to set their own limits to that, of course.

Let’s say, for example, that a legitimate yet reckless user requests the download of the zipped contents of a folder containing 100,000 files, each file having an average size of 100 MB. We’re talking about 10TB of data to be compressed. We’re talking about a potential VM-killer.

So, with WebClient! v2, administrators will be able to limit the processing of the zip archive to a predefined maximum number of files and/or a predefined maximum size before compression, whichever comes first.

Here’s a few possible configuration examples:

  • zip downloads may not exceed 1,000 archived files
  • zip downloads may not exceed 200 MB of data (before compression)
  • zip downloads may not exceed 1,000 files or 200 MB of data, whichever limit is hit first

If a limit is hit, the client will still receive a perfectly functional zip archive, but a 206 response code (partial content) instead of the typical 200 response code (OK), to signify that the request was only partially fulfilled, and the limit that was hit will be clearly identified by a set of X- headers in the HTTP response.