Preserve Partial SFTP Uploads After Disconnects

When an SFTP client disconnects before finishing an upload, Files.com needs to decide what to do with the data received so far. The Preserve Partial SFTP Uploads After Disconnects setting gives you control over this behavior.

Preserving partial uploads allows interrupted transfers to be resumed, but incomplete files will be visible on your site and may trigger automated actions or other downstream processing.

Discarding partial uploads prevents incomplete files from appearing on your site, but any interrupted transfer must be restarted from the beginning.

How Files.com Detects Upload Completion

The SFTP protocol uses an SSH_FXP_CLOSE message to signal that a client has finished writing a file and is explicitly closing the file handle. Files.com treats the receipt of SSH_FXP_CLOSE as confirmation that an upload is complete.

If a client disconnects without sending SSH_FXP_CLOSE Files.com has no way to determine whether the remaining data will be sent later or never at all. A missing SSH_FXP_CLOSE message is usually caused due to a network interruption, the client process being terminated, or a client crash.

Setting Behavior

This setting is enabled by default. When enabled, Files.com preserves any data received so far if the SFTP client disconnects before sending SSH_FXP_CLOSE. The partial file remains on your site at its upload destination, allowing the SFTP client to resume the upload later by appending the remaining data.

However, these partial files will be visible on your site and will trigger Automations, webhooks, or other downstream processing that expects complete files.

When this setting is disabled, Files.com discards any data received if an SFTP client disconnects without sending SSH_FXP_CLOSE. Incomplete uploads are deleted automatically, so partial files will not appear on your site and will not trigger Automations or other downstream processing.

Disabling this setting removes the ability for SFTP clients to resume interrupted uploads. If a transfer is interrupted, the client will need to restart the upload from the beginning.

Choosing the Right Setting

Enable this setting when your workflow involves large file transfers or connections that are prone to interruption, and your user's and customer's SFTP client supports resumable uploads by appending data to a partially uploaded file. In these cases, preserving partial data allows the client to continue from where it left off rather than restarting the entire upload.

Disable this setting when your Automations, webhooks, or downstream integrations, are triggered by file arrival and must only process complete files. When partial uploads are preserved, incomplete files appear at the upload destination and may trigger unintended processing. Discarding partial uploads ensures that only fully completed transfers become visible on your site.

If resumability is not a requirement, disabling this setting is the more predictable option. Any interrupted transfer will be discarded automatically, and the client will need to restart the upload from the beginning.

Logging

When an incomplete upload is discarded, the SFTP session log will record the transfer with a status of Discarded Partial Upload.

If you see unexpected Discarded Partial Upload entries for transfers that you believe should be completing successfully, this indicates that the SFTP client is not sending SSH_FXP_CLOSE at the end of a successful upload.

SFTP Protocol Compliance

Both behaviors are fully compliant with the SFTP protocol specification. The SFTP standard defines how servers must handle SSH_FXP_CLOSE when it is received, but does not specify what a server must do when a client disconnects without sending it. Preserving or discarding partial data in that scenario is an implementation choice, and Files.com supports both behaviors via this setting.

SFTP Client Inconsistencies

It is important to understand that SSH_FXP_CLOSE behavior varies significantly across SFTP client implementations. Some clients send SSH_FXP_CLOSE when an upload is aborted or interrupted, and some do not. When a client does send SSH_FXP_CLOSE after an incomplete upload, Files.com has no way to distinguish that file from a successfully completed one.

If you are uncertain whether your SFTP client sends SSH_FXP_CLOSE on abort, the only reliable way to confirm this is to enable debug or verbose logging in your SFTP client and inspect the session log for the presence or absence of an SSH_FXP_CLOSE or SSH2_FXP_CLOSE message following an interrupted transfer.

How to enable debug logging varies by client. Refer to the documentation for your specific SFTP application or library. For PowerShell scripts using WinSCP, session logging can be enabled via the SessionOptions log path setting. For applications with a built-in SFTP client, look for a debug, trace, or verbose logging option in the application's connection or transfer settings.