Syncplify Server! v6.2.27 released

Importance of this update: [ROUTINE UPDATE]
What’s changed?
  • Upgraded some package dependencies to incorporate various bug-fixes in external libraries
  • Fixed a bug in parametric VFS that occasionally caused directories to be created on physical storage with names enclosed in square brackets
  • Significantly improved the way files are downloaded via WebClient!: downloads now use less memory and are much faster (other protocols like FTP and SFTP are unchanged)

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!

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.