No Syncplify software uses (nor has ever used) anything written in Java. Furthermore, and more specifically, no Syncplify software uses (nor has ever used) Log4j. Therefore, none of our software is affected by (nor it has ever been) any Log4j bug or vulnerability.
Recently we had the chance to help one of our customer achieve a data synchronization task, which spawned an unusual cooperation that gave birth to a tale worth telling. So, here we go.
Our customer was using Syncplify.me AFT!, our scriptable secure file transfer client, to automate some unattended data synchronization tasks.
One of these tasks was failing with an unusual error message. At first we didn’t think much of it, because it seemed to be just a refusal from the server to set the file last modification date after the upload, which is a very common scenario, and AFT! handles it gracefully.
Upon further investigation, though, turns our that the error message had deeper roots.
That’s when the conversation was broadened, to include the vendor of the server software as well: the server in question was SFTP To Go, by Crazy Ant Labs.
Crazy Ant Labs’ support staff was courteous, and very quick at pointing out that since SFTP To Go’s back-end storage is based on AWS S3, it also inherits some of S3’s well-known “quirks”. In this particular case it was an unsupported set of file-open flags.
Thanks to this rational assessment, our team was able to quickly release a new minor version of AFT! that specifically addresses this limitation, while also retaining the previous broader set of file-open flags for those cases that support them, automatically determining which file-open flag set should be used on a case by case manner.
We all here at Syncplify were impressed with the courtesy and professionalism of the Crazy And Labs’ staff, who have been most helpful both in identifying the problem in the first place, and in providing precise feedback to help us resolve it.
Good cooperation between software vendors in the same space led to a customer success story for all the parties involved.
Yes, V6 is the most anticipated Syncplify Server! version since the software was first released back in 2014… but for our company, and for our customers, it means much more than that. In fact:
Let’s keep moving forward. Together. 🙂
As you all probably already know, one of the main goals for Syncplify Server! v6 and AFT! v4 is uniformity. And one of the major steps taken to achieve such uniformity is the adoption of the same scripting language in both software products.
Since aftJS (the JavaScript flavor found in AFT!) was way more modern and powerful than any scripting support ever incorporated into Server!, adopting it seemed to be the only sensible choice.
But now we have a problem: the name, aftJS, is so tightly coupled with a specific product (AFT!) that it would spawn confusion if adopted in the context of our flagship product, Syncplify Server!
Renaming the language, therefore, appears to be not only a more uniform choice, but it is also our chance to tie our scripting language to who we are as a company.
So… Syncplify’s JavaScript… SyncJS.
This is a technical blog. And it has two main purposes:
1) To share ideas and insights into the development of the next features in Syncplify’s products with other developers and system administrators who routinely use our software
2) To publish Release Notes every time a new version (whether it is a minor update or a new major version) of a Syncplify product is released
Questions like “when is feature XYZ going to be included in your product?” or “what are you guys developing right now?” often find answers in this blog (and, frankly, nowhere else).
The typical audience of this blog is composed of tech enthusiasts and actual current administrators of Syncplify software, who want to know more – and ahead of time – what’s coming in the next minor revisions and/or major releases of our software, as well as be kept up to date with bug-fixes and other important information.
Thank you for following us, we’ll do our best to keep you engaged.
