Soon, soon, soon!

Here is the complete addition:

File operations: GzipFile, GunzipFile, FileAgeSecs, FileSizeOf, WaitForFile, SplitFileByLines, SplitFileBySize

Data and encoding: ParseCSV, FormatCSV, ParseXML, Base64Encode, Base64Decode, HashString, FormatDateTime

Cryptography: HmacSign, HmacVerify, PGPSignFile, PGPVerifyFile

Integration: RunCapture, TcpConnect, SendToTeamsWebHook

The three additions that change the most scripts

HMAC signing and verification. HmacSign and HmacVerify implement the pattern behind every major webhook security model: GitHub, Stripe, Slack, and virtually every cloud event system use HMAC-SHA256 to authenticate payloads. Until now, doing this from a SyncJS script meant shelling out to an external tool. That workaround is gone. Both functions support SHA-256 and SHA-512. HmacVerify uses constant-time comparison, so it is safe in authentication paths.

var key     = GetSecret("webhook-secret");
var sig     = HmacSign("sha256", key, payload);
var trusted = HmacVerify("sha256", key, payload, incomingSig);

Native CSV and XML parsing. The majority of real MFT scripts exist to read, transform, or route files based on their contents, not just their filenames. ParseCSV returns a two-dimensional array of strings. ParseXML returns a nested JavaScript object with a predictable structure: attributes under _attrs, text content under _text, repeated elements as arrays. Neither function requires a child process or an external dependency. The data is just there, in memory, ready to drive routing logic.

var rows = ParseCSV(ReadTextFile("/inbox/orders.csv"));
var doc  = ParseXML(ReadTextFile("/inbox/manifest.xml"));
Log("order count: " + rows.length + ", ship-to: " + doc.order._attrs.destination);

WaitForFile. If you have written a SyncJS script that waits for an upstream process to drop a trigger file, you have written the sleep/check/repeat loop manually. WaitForFile replaces it entirely. Pass a path, a timeout in milliseconds, and an optional poll interval. Get a boolean back.

if (!WaitForFile("/processing/trigger.flag", 30000)) {
  Log.Warn("trigger file did not arrive within 30 seconds");
  Exit(1);
}

The rest, in brief

GzipFile and GunzipFile compress and decompress single files in place or to a named destination. SplitFileByLines and SplitFileBySize partition large files into numbered chunks, the prerequisite step for any parallel-upload pattern. FileAgeSecs and FileSizeOf return exactly what the names say, useful for conditional logic without a full StatFileSystemObject call.

PGPSignFile and PGPVerifyFile extend the existing PGP encrypt/decrypt pair with detached signature support. HashString brings string-level hashing to the same eight algorithms already supported by HashFile. Base64Encode and Base64Decode handle the encoding required by virtually every HTTP API.

RunCapture turns the output of any OS command into a string your script can use directly. TcpConnect checks whether a host and port are reachable before committing to a full connection. SendToTeamsWebHook joins Slack and Telegram in the notification options. FormatDateTime formats timestamps using token-based patterns without requiring the standard library workarounds that JavaScript developers normally reach for.

In conclusion

Full documentation for every new function is in the SyncJS scripting reference. If you write scripts in VSCode, the Language Server extension picks up all new symbols automatically after updating. No reinstall required.

And it doesn’t end here. SyncJS is becoming more and more central to the life and interoperation of all Syncplify software products, so we’re fully committed to its constant upkeep and improvement.

What’s changed in Server!?

• Bumped the scripting subsystem to SyncJS v4.1.2, which adds 21 brand new utility functions to the language

• Fixed a bug in the Admin UI that prevented clearing the SMTP configuration

• Improved UX of the WebClient! UI to more explicitly incorporate the new browser security restrictions with regards to OS interoperation with the file/directory selectors during uploads

What’s changed in R2FS!?

• Bumped the scripting subsystem to SyncJS v4.1.2, which adds 21 brand new utility functions to the language (same as in Server!)

Please, also read this note which pertains to all updates/upgrades. And, as usual, you can download the most recent release from our website.

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

Given that over 90% of developers work in VSCode or one of its derivatives, that was the obvious place to start.

SyncJS is 100% ECMA 5.1-compliant JavaScript at its core, but it also adds 200+ functions, methods, structures, and symbols on top of the base language. Expecting every developer to memorize that extended API was never realistic.

So we built a VSCode extension that solves both problems at once: a full Language Server for inline documentation and auto-completion, and an MCP (Model Context Protocol) server so AI agents can write SyncJS scripts for you without hallucinating methods or structures that don’t exist.

Here’s how to get set up.

1. Install the SyncJS extension

Search for SyncJS in the VSCode Extension Marketplace and install it.

2. Register the MCP servers in your User profile

Once installed, open the command palette with Shift+Ctrl+P and run: SyncJS: Register SyncJS MCP Servers in User Profile.

Reload your VSCode window when prompted for the change to take effect.

3. Add a SyncJS MCP server to your project

After reloading, open the command palette again and run MCP: List Servers.

Select the SyncJS flavor that matches your project: core SyncJS (symbols shared across all Syncplify products), or the extended symbol tables specific to Server! or AFT!.

4. Prompt your AI agent

That’s it. Your AI agent now has precise, complete knowledge of the SyncJS language: its syntax, object model, and the full functional API. Write your prompt as you normally would.

5. Your SyncJS script is ready

The agent produces a working SyncJS script. Review it, make any adjustments you want, then paste it directly into your Syncplify product’s web UI.

The SyncJS VSCode extension is available today. Whether you prefer writing scripts by hand with full auto-completion and inline documentation, or delegating the first draft to an AI agent that actually knows the language, the tooling is there.

Install it, connect your agent, and let SyncJS do the heavy lifting across your entire Syncplify environment.

What’s changed in Server!?

• Extracted the SyncJS scripting language (Syncplify’s very own extended version of JavaScript built on top of the ECMA 5.1 standard with the addition of many dedicated functions, methods, and types) into an independent shared library so that it can be ported to R2FS! and AFT! as well with perfect consistency

• Removed deprecated ioutil package (Go) and switched to the recommended alternatives (io, os, etc…)

• Fixed a bug with the multiplexed session counter for SSH-based subsystems which could, in certain conditions, “forget” to decrement the number of total active sessions in the dashboard

• Fixed several cosmetic (and one functional) bugs in the Admin UI

What’s changed in R2FS!?

• Added full SyncJS scripting and event-handling (uses the same SyncJS extended version of JavaScript also available in the Server! software) - now you can run your SyncJS scripts on the storage side as well!

• Added indexed/searchable VFS-level “op log” directly in R2FS!’s back-end database (does not substitute log files, which are still there for full auditing trail)

Please, also read this note which pertains to all updates/upgrades. And, as usual, you can download the most recent release from our website.

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

Every file operation is recorded with timestamp, operation type, VFS, user, path(s), bytes received and sent, duration, and error status. You can filter by time range, operation, user, VFS, or any combination thereof. Precisely the kind of granular, on-demand visibility that system administrators have always wanted when something needs investigating.

A quick clarification, though, for the security-conscious reader: this is not a replacement for the digitally signed, tamper-evident log files you already rely on. Those aren’t going anywhere.

The operation log is a complementary tool, optimized for interactive exploration rather than compliance attestation. Think of the signed log files as your forensic record and the op-log as your operational sidekick, both live side by side, each doing what they are designed to do.

As with SyncJS support, we’re not ready to commit to a specific release date, but v2.0 is close. Maybe even closer than you think.

Well, starting with R2FS! v2.0, you will have it. When this release lands, you’ll be able to execute SyncJS scripts not just on the server side (as always), but directly on the storage side via the R2FS! storage connector.

That means your event-driven logic can live where your data lives, opening up automation patterns that simply weren’t possible before.

And because SyncJS scripts are already fully portable between Syncplify Server! and R2FS!, any script you’ve written and tested today will run without modification tomorrow (with the exception of server-only contexts that simply don’t exist in R2FS!, but that’s obvious).

We’re not ready to announce a specific release date yet, but R2FS! v2.0 is on the near horizon. Stay tuned.

When you move your organization’s file transfer operations to a cloud MFT platform, you typically hand your data to a third party. That’s the obvious part, the part everyone understands and accepts as the trade-off for convenience and scalability. What’s less obvious, and far less discussed, is what happens to certain encryption keys.

Most cloud MFT platforms encrypt your data at rest. They’ll tell you this proudly, and technically, they’re telling the truth. What they’re less eager to explain is that in the overwhelming majority of cases, they also manage the encryption keys. Their infrastructure. Their key management system. Their access.

Which means, if you read between the lines: they can decrypt your data. Not because they want to, not because they’re malicious, but simply because the architecture permits it.

Why This Matters More Than You Think

Consider what that architectural reality means in practice.

It means that a sufficiently serious breach of your vendor’s infrastructure is also a breach of your data, regardless of how strong the encryption algorithm is. Encryption only protects data if the keys are out of reach. When the keys live alongside the data in the same vendor environment, you don’t have two locks on the door. You have one.

It means that a subpoena, a national security letter, or a government inquiry directed at your vendor potentially becomes your problem, even if your organization was never the target. Your data’s legal exposure is no longer purely a function of your own legal standing.

It gets worse: It means that a rogue insider at your vendor has a theoretical path to your most sensitive files. Again, not likely. But in regulated industries, “not likely” is not a compliance posture.

It means, bluntly, that you’ve outsourced not just the infrastructure but the trust model itself.

The Industry Has Normalized Something It Shouldn’t Have

The uncomfortable truth is that most organizations never ask these questions during vendor evaluation. “Do you encrypt data at rest?” gets a yes, the checkbox gets checked, and the conversation moves on. The far more important question, “Who holds the encryption keys, and what would it take for someone other than us to access them?”, rarely gets asked.

This isn’t a criticism of IT and security teams. The cloud MFT market has spent years (and a remarkable amount of dollars) conditioning buyers to treat server-side encryption as sufficient. But it isn’t. Not for organizations operating in regulated industries, not for organizations handling sensitive partner data, and not for any organization that takes data sovereignty seriously.

The standard should be simple: your data should be encrypted in a way that makes it technically impossible for anyone other than you to access it. Not policy-impossible. Not contractually-impossible. Technically impossible.

What Good Actually Looks Like

True data sovereignty in a cloud file transfer context requires one thing above all else: encryption keys that never leave your control, managed on infrastructure you own, in a network you control.

This means the encryption and decryption of your data at rest happens on your side of the boundary, not your vendor’s. It means your vendor’s cloud infrastructure acts as a secure, highly available relay, moving encrypted data it cannot read, between parties it authenticates but cannot impersonate. It means that even in the worst-case scenario, a complete compromise of the cloud layer yields nothing useful to an attacker, because the keys were never there.

This architecture exists. It’s not theoretical, it’s not exotic, and it doesn’t require sacrificing the operational benefits of a managed cloud service.

It does, however, require vendors who were willing to build it that way from the ground up, rather than retrofit the appearance of security onto a model that was never designed with true key separation in mind.

At Syncplify, we’ve always believed that the right answer to “who holds the keys?” is unambiguous: you do. Always. Without exception.

We’ll have more to say about how we’ve put that belief into practice. Stay tuned.

What’s changed?

• Fixed a WebClient! UI bug that was recently introduced, which prevented multi-file/folder, nested, batched uploads, and improved the upload UX at the same time

• Fixed 3 more accessibility issues in the WebClient! UI

• Fixed a sanitization step in the Admin UI’s VFS page which, in some cases, would prevent saving the at-rest encryption passphrase for cloud-based VFS types (S3, Azure, GCP)

• Used more efficient “scroller” based approach for configuration backup and restores, which improves the speed of these two operations by about 15%, and provides for more granular and graceful error handling

Please, also read this note which pertains to all updates/upgrades. And, as usual, you can download the most recent release from our website.

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

Once again, Syncplify is happy to report that none of our products is affected. Like Heartbleed, like Terrapin, and now like this: Syncplify software is safe by design.

Not “does it support SFTP?” Not “can it integrate with our storage?” Not even “how does it handle high concurrency?”

The question is: Has it ever been breached? Does it have a CVE record?

That two-part question, asked seriously, changes the conversation entirely.

What the Category Has Been Through

Managed file transfer is not a quiet corner of enterprise software. Over the past several years, it has been one of the most actively targeted categories in the threat landscape. Vulnerabilities in widely deployed MFT platforms have been exploited at scale, leading to data breaches affecting hundreds of organizations at a time, across finance, healthcare, government, and critical infrastructure.

Anyone who follows security news knows exactly which incidents we are referring to. And the organizations affected were not careless. Many had security teams, compliance programs, and vendor due diligence processes. They simply trusted platforms that turned out to have exploitable flaws.

In file transfer, the software itself is often the attack surface.

What Zero CVEs Actually Means for a Compliance Buyer

Syncplify Server! had its first public release in 2013. As of today, it has never had a single CVE entry in the NIST National Vulnerability Database, and it has never been the subject of a successful breach.

That is twelve years of continuous operation in one of the most hostile software categories in enterprise IT.

When your organization undergoes a SOC2 audit, an ISO 27001 review, a HIPAA assessment, or a regulatory examination, one of the most uncomfortable questions an auditor can ask is: “Has any component of your file transfer infrastructure ever had a known exploitable vulnerability?”

With Syncplify Server!, the answer is simply no. No caveats, no remediation history, no patch timelines, no incident response documentation. Just no.

That is a different position to be in than most.

Why the Architecture Matters More Than the Track Record

A clean record is only as meaningful as the engineering decisions behind it.

Syncplify Server! was designed from the ground up with a narrow, well-defined scope. It does not carry decades of legacy protocol baggage. It does not have a sprawling plugin ecosystem that expands the attack surface. Every feature was added deliberately, with security properties considered as part of the design, not bolted on afterward.

The reverse-connection storage model in R2FS!, the cryptographically signed audit logs added in v7.0.14, the SyncJS scripting sandbox: these are not marketing features. They are the visible surface of a design philosophy applied consistently since day one.

The CVE record is a consequence of that philosophy. Not a lucky outcome.

For Organizations Where the Answer Matters

If your organization operates in financial services, healthcare, life sciences, government, or any environment where the data moving through your file transfer infrastructure is regulated, sensitive, or irreplaceable, the security posture of the platform itself is not a secondary concern. It is a primary one.

In those environments, a twelve-year zero-CVE record is not a footnote.

The NIST NVD is public. The record speaks for itself. Anyone can independently verify the claims we made here above.

What’s changed?

• Vastly improved tombstone management for the HA synchronization database, making the sync operation between HA nodes up to 10x faster

• Fixed a glitch in the configuration of at-rest encryption that only affected Azure and GCP VFs types

• Added “Secret” management to the Admin UI and GetSecret method to the scripting engine, to safely store encrypted secrets in Syncplify Server!’s database and use them from your event-handling scripts

• Ported over all the “client objects” from AFT!, they are now all also available in Syncplify Server!’s scripting engine (reached 100% parity of features)

• Resolved a few minor accessibility issues in the SuperAdmin, Admin, and WebClient! UIs

• Updated OpenAPI definitions and software manual to reflect the new features and capabilities

Please, also read this note which pertains to all updates/upgrades. And, as usual, you can download the most recent release from our website.

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

What’s changed?

• Added the ability to specify a custom HELO/EHLO string in the SMTP configuration settings

• Fixed a WebClient!-specific glitch that prevented users authenticated from LDAP groups from sharing files/folders, but only when the Home-VFS had dynamic parameters in its target configuration

• Resolved a few minor accessibility issues in the SuperAdmin, Admin, and WebClient! UIs

Please, also read this note which pertains to all updates/upgrades. And, as usual, you can download the most recent release from our website.

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

For organizations operating in highly regulated markets, that is no longer enough.

When a security incident, compliance review, customer dispute, or forensic investigation happens, the key question is not simply whether an event was logged. The real question is whether the audit trail itself can still be trusted.

That is why Syncplify Server! v7.0.14 introduces cryptographically secure, digitally signed, forensically auditable logs.

This feature is built for organizations where audit integrity is not optional. Financial services, healthcare, life sciences, government, and other regulated sectors need more than visibility. They need defensible records. They need tamper evidence. They need to know that if someone attempts to alter the history of a transfer after the fact, that alteration will not go unnoticed.

Plain logs are useful for troubleshooting. In high-accountability environments, though, they are not enough. They can record a story, but they do not necessarily prove that the story remained intact.

Digitally signed audit logs are designed to address that.

With v7.0.14, Syncplify Server! strengthens the integrity of the audit trail itself. That gives security, compliance, and executive leadership something stronger than “we captured the event.” It gives them a record for which integrity can be verified.

For CTOs, CIOs, CISOs, and other technical decision-makers, this matters for a very practical reason: file transfer systems often sit directly in the path of sensitive business processes. Financial records, healthcare data, regulated documents, legal archives, claims, reports, exports, and customer files all move through these systems. When they do, the surrounding audit trail can become just as important as the transfer itself.

And when scrutiny arrives, organizations are expected not only to have controls in place, but also to demonstrate that those controls were real, effective, and enforced. That is much easier to do when the integrity of the underlying logs does not depend on trust alone.

If a regulator, auditor, customer, or incident response team asks whether the logs can be relied upon, “we have logs” is not the strongest possible answer.

“We have logs whose integrity we can defend” is.

That is the difference Syncplify Server! v7.0.14 is designed to make.

If your organization operates in a market where auditability is not optional, v7.0.14 is a release you will want to prioritize.

What’s changed?

• Fixed the SSSync database collections for HA-nodes that were previously upgraded from an old Syncplify Server! version 6.x. If you have an instance of a high-availability set that was upgraded from v6.x, please, bear in mind:

  • Upgrading to v7.0.14+ is absolutely necessary to resolve inter-node synchronization issues, and prevent future ones

  • This upgrade may take a very long time (even > 10 minutes in some cases), let the installer run, it’s not stuck, please be patient

• Added (optional) cryptographically secure and auditable log file “rolling” digital signatures, forensically provable, ideal for customers working in highly regulated environments (dedicated blog post coming soon on this topic)

• Added the ability to optionally cycle (rotate) log files on a daily basis, in addition to the size-based rotation logic which is still present

• Fixed the behavior of the LIST command in the FTP(E/S) protocol handler to correctly handle wildcard restrictions

• Further refinement to the dereferencing of AD group users with regards to objects (directories and files) shared via WebClient! which now correctly honor parametric VFS configurations for this type of users

• Upgraded the back-end SyngoDB to the most recent version which comes with significant performance improvements

• Fixed a few minor glitches in the SuperAdmin and Admin UIs

Please, also read this note which pertains to all updates/upgrades. And, as usual, you can download the most recent release from our website.

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

That design keeps the storage subnet completely private (no inbound firewall rules, no NAT, no mounted shares) but it also raises an obvious question:

How much performance do you lose?

To find out, we ran a quick stress test using our internal multi-protocol testing tool called Grinder.

Same server, same network, same client, same settings; The only difference was the storage target.

On the left, files are written to the Syncplify Server!’s local disk.

On the right, the same workload is written to a NAS located in a private subnet, reached through R2FS!.

The local disk test reached about 130 MB/s.

Through R2FS!, with two extra network hops, encryption, and a reverse tunnel, the transfer rate was still around 120 MB/s. That’s only a 7.7% performance penalty!

That’s the key takeaway.

When adding R2FS! into the mix, the performance impact is surprisingly small! Small enough, in fact, that in most real-life deployments the added isolation (security) is easily worth it.

Remember that in this setup the storage system never accepts inbound connections at all. The R2FS! agent connects outbound to Syncplify Server!, which means the backend can stay behind a strict firewall while still being exposed as a VFS on the server.

You get segmentation, scanning, and controlled access, without turning your storage network into part of the DMZ. And all this without sacrificing performance.

For completeness: yes, the stress tool shown in the screenshot is ours.

We built Grinder in-house to test Syncplify Server! and R2FS! under high concurrency across SFTP, HTTPS, and FTP/FTPS, and it’s what we use internally to validate designs like this.

R2FS! was designed to improve security, not speed, but it’s nice to see that you don’t have to give up much performance to get it.

“Yes. This is exactly what these features were built for.”

Recently, one of our enterprise customers shared a planned architecture for a secure file-transfer workflow using Syncplify Server! v7 together with Syncplify R2FS!, and we were genuinely impressed by how clean, safe, and flexible the design is.

With their permission (and with all identifying details removed), we’re sharing this use-case because it perfectly demonstrates how Syncplify’s VFS, Virtual Folders, SyncJS, and R2FS! can be combined to build a zero-trust ingestion pipeline without any extra middleware... and without exposing internal storage to the network.

The Problem

The customer needed to solve a very common (yet very tricky!) requirement:

• External clients must upload files

• Files must be scanned before reaching internal storage

• Internal storage must never be exposed directly

• Outbound files must still be accessible immediately

• Upload workflows may use temp files, renames, or staging folders

• The storage subnet must not accept inbound connections

• No NAT or port-forwarding to internal storage should be required

In other words: Allow file transfers, but never trust them, and never expose the backend.

The Key Idea

Instead of letting users write directly to backend storage, the customer designed a pipeline where:

1. Files land on the Syncplify Server! local disk

2. A script scans them

3. Only clean files are moved to backend storage via R2FS!

4. Backend storage is exposed back to the user as read-only

This turns Syncplify Server! into a security gate, and R2FS! into a secure outbound bridge to internal storage.

The crucial detail here is that R2FS! connects outbound from the storage side, meaning:

• No inbound firewall rules are required

• No NAT is required

• No port forwarding to the storage network

• The storage subnet remains completely private

This is the main reason R2FS! exists.

You can read more about this architecture here:
https://www.syncplify.com/syncplifyr2fs

High-Level Architecture

At a high level, the system works like this:

• Users upload into a staging area on Syncplify Server!

• Event handlers trigger scanning

• Clean files are copied to an R2FS! VFS

• R2FS! delivers them to internal storage through an outbound-only connection

• Internal storage is exposed back to the user as outbound folder

The most important rule in this design is: No file can ever reach internal storage unless the script allows it, and the storage network never accepts inbound connections.

Why R2FS! Is Critical Here

In a traditional setup, the Syncplify host would need direct access to backend storage via:

• SMB/CIFS

• NFS

• mounted disk

• VPN

• port forwarding

• firewall rules

All of these increase the attack surface.

With Syncplify R2FS!, the model is reversed.

The storage system connects outbound to Syncplify Server!, not the other way around.

This provides several major security benefits:

• No inbound connectivity to the storage subnet

• No NAT rules required

• No port forwarding required

• Storage can sit behind a strict firewall

• Backend can even be in a different network zone

• Syncplify Server! never needs direct file-system access to the actual data storage

This makes R2FS! ideal for:

• DMZ-to-internal storage bridges

• zero-trust architectures

• segmented networks

• high-security environments

Exactly the scenario this customer implemented.

Using Virtual Folders to Separate Inbound and Outbound

The user’s home directory is built using:

• Local disk VFS for inbound files

• R2FS! VFS injected as a virtual folder for outbound files

This ensures:

• Uploads go only to staging

• Internal storage is read-only for the user

• Backend storage is never written directly

Because virtual folders currently mount entire VFS objects, the customer created two VFS per customer:

• one for inbound staging

• one for outbound R2FS!

This is only a convenience limitation, not a functional one, and the design remains very clean.

Handling Real-World Upload Workflows

Real clients rarely upload files in one step.

Common patterns include:

• .tmp during upload

• write -> rename

• upload to /temp

• move after complete

If scanning runs too early, the file is incomplete.
If scanning runs too late, unsafe data could pass through.

The solution was to trigger the script on:

• AfterFileUpload

• AfterFileRename

and ignore temporary files.

Example logic:

• Ignore .tmp

• Ignore /temp/

• Scan only finalized files

This ensures scanning runs exactly once, at the right time.

SyncJS Automation + External Scanner

The entire secure move to backend storage is handled with SyncJS, including calling an external scanning tool.

Example script:

var originVfs = GetCurrentVFS();

if (originVfs == null) {
  Exit();
}

var fname = Session.GetRelPath();

// ignore temp files

if (fname.endsWith(”.tmp”) || fname.indexOf(”/temp/”) >= 0) {
  Exit();
}

// run external scanner (example)

var scan = Run(”powershell.exe”, “-File C: \\scripts\\ scan.ps1\”“ + fname + “\”“);

if (scan.ExitCode != 0) {
  Log(”Scan failed, file not accepted”);
  Exit();
}

var recipientVfs = new VirtualFSByName(”r2fs_vfs1”);

if (recipientVfs != null) {
  var resp = originVfs.CopyToVFS(fname, recipientVfs, fname);
  if (resp.Ok()) {
    Log(”File copied to R2FS VFS”);
  } else {
    Log(”Error: “+resp.ErrorMsg());
  }
}

This script:

• avoids uploads that are not yet complete

• runs an external scan

• copies only clean files

• sends them to the R2FS! VFS

• lets R2FS! deliver them to internal storage

No middleware required.

Security Properties of This Design

This architecture guarantees:

• No un-scanned file reaches backend storage

• Internal storage never accepts inbound connections

• No NAT or port forwarding required

• Syncplify is the only exposed service

• Backend stays isolated

• Any scanner can be used

• Upload workflows remain compatible

• Outbound files are immediately visible

This is effectively a zero-trust file gateway built entirely with Syncplify software.

Where This Pattern Works Best

This architecture is ideal for:

• Media ingest pipelines

• Broadcast / MAM systems

• Financial data exchange

• Healthcare file intake

• Government secure transfers

• Segmented enterprise networks

• Air-gapped storage environments

• Zero-trust infrastructure

Final Thoughts

We love seeing customers use Syncplify products this way.

This deployment combines:

• Virtual File Systems

• Virtual folders

• SyncJS scripting

• Event handlers

• External scanning

• R2FS! outbound storage bridge

to create a secure, elegant, and fully automated file pipeline, without adding extra servers, without opening firewall holes, and without exposing internal storage.

Exactly the kind of architecture these features were designed for.

What’s changed?

• Vastly improved the dereferencing of AD user account data for “LDAP Group” accounts, for which the maximum number of concurrent connections per user will now take into account the actual UPN of the user in the group in which they have been authenticated

• Fixed three minor/cosmetic bugs in the WebClient! UI (these bugs did not affect its functionality, nevertheless we keep trying to improve all aspects of our UIs and we act upon our customers’ reports)

Please, also read this note which pertains to all updates/upgrades. And, as usual, you can download the most recent release from our website.

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

What’s changed?

• Improved support for directory-symlinks on the storage server side: dereferencing (and therefore STAT support) is now 100% automatic and handled by R2FS! internally and seamlessly.

As usual, you can download the most recent release from our website.

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

What’s changed?

• Fixed a critical bug related to lock-synchronization that affected the Windows version of our Web/REST service, exclusively limited to the high-availability (HA) subsystem - customers running Syncplify Server! in stand-alone or single-node deployments can safely skip this update.

Please, also read this note which pertains to all updates/upgrades. And, as usual, you can download the most recent release from our website.

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