The SFTP protocol allows files to be partially uploaded. It provides the capability for data to be appended to the partial file, in anticipation of the rest of the file being uploaded later.

Unfortunately, an SFTP server is unaware of whether an uploaded file is complete or partial. Only the client app knows if there is remaining data to be uploaded later. To make matters worse, there's no way for a server to know what "later" means for a client app. The remaining data might be sent a few minutes, hours, or days later or never at all.

Some SFTP client apps implement an approach that uses a temporary file to upload into and then renames the temporary file to its target name. For example, when uploading file.csv a client will upload into a file named something like file.csv.filepart and then, after the complete file contents have been uploaded, rename file.csv.filepart back to file.csv.

SFTP client apps will only be able to resume the upload if the partial file remains at its location. Moving, renaming, or processing a partial file will remove the ability for the SFTP client app to resume the upload.

To avoid partially uploaded files, use a Files.com native app to perform atomic uploads instead.

If your counterparty is limited to using SFTP then try and mitigate the propagation or processing of partial files. Do not implement automations, encryption, or Folder Settings on destination folders of SFTP uploads as these will act upon partial files. Try and target file name patterns that omit partial, or temporary, file names. Use schedules to delay actions on uploaded files. For example, if you expect files to be uploaded at 9 am then use an automation with a custom schedule set for 10 am, so that you allow an extra hour for any remaining data to be uploaded.