An SFTP client can write a file in several requests and return later to append more data. This lets it resume an interrupted upload, but file presence alone does not establish that all of the intended contents have arrived. That distinction matters when an upload feeds an Automation, webhook, encryption step, or another system.

Files.com provides the Preserve Partial SFTP Uploads After Disconnects setting to control what happens when a client disconnects without closing its upload. The choice is between retaining data so the client can resume and discarding that data so an interrupted upload does not enter downstream processing.

For workflows that can use a Files.com native app, atomic uploads avoid exposing partially uploaded files.

Upload Completion

An SFTP client closes an uploaded file by sending SSH_FXP_CLOSE. Files.com treats that message as confirmation that the upload is complete. If the client disconnects without sending it, the server cannot know whether the client will send more data later. A network interruption, a terminated process, or a client crash can leave an upload without this closing message.

Client behavior matters even when the message is present. Some clients send SSH_FXP_CLOSE after an upload is aborted or interrupted. Files.com cannot distinguish a file closed that way from a successfully completed upload, so the preservation setting cannot guarantee that every closed file contains all of the data the producer intended to send.

The SFTP protocol specification defines closing a file handle, but does not require preserving or discarding data when a client disconnects without closing it. Files.com supports both choices.

Preserve Partial SFTP Uploads After Disconnects

This setting is enabled by default. When enabled, data received before the disconnect remains at the upload destination. A client that supports resumable uploads can append the remaining data later rather than start again. The partial file is visible and can trigger Automations, webhooks, and other processing.

When the setting is disabled, Files.com discards uploads whose client disconnects without sending SSH_FXP_CLOSE. These incomplete uploads are deleted and do not appear as files or trigger downstream processing. An interrupted transfer must restart from the beginning.

Preserving partial data is useful for large transfers or connections prone to interruption when the client supports resuming uploads. Discarding it is the more predictable choice when resumability is not required or processing is triggered by file arrival. This choice applies to uploads left open at disconnect; it cannot detect an incomplete file that the client explicitly closes.

Resumable Uploads and Downstream Processing

A resumable upload must remain at its original location. Moving, renaming, or processing the partial file prevents the client from resuming it there. Avoid automatic content processing, encryption, or renaming on the folder receiving those uploads until the client has completed them.

Some clients upload under a temporary name, such as file.csv.filepart, and rename the file to file.csv after sending all its contents. Configure the consuming Automation or script to exclude the temporary name and act on the final name. This works only when the client retains the temporary name until the upload succeeds and then renames the completed file.

A scheduled delay can give a transfer time to finish. For example, a workflow expecting an upload at 9 am can defer processing until 10 am. The delay does not prove completion: a transfer can take longer than expected, be interrupted, or never resume. The client's completion behavior must establish when the file is ready.

Discarded Uploads and Client Logs

When Files.com discards an incomplete upload, the SFTP session log records the transfer with the status Discarded Partial Upload. An unexpected entry for a transfer the client considers successful indicates that the client did not send SSH_FXP_CLOSE at the end.

To determine whether a client closes an aborted upload, enable its debug or verbose logging and inspect the session for SSH_FXP_CLOSE or SSH2_FXP_CLOSE after the interruption. Applications may call this option debug, trace, or verbose logging. Refer to the documentation for the specific SFTP application or library.