Partially Uploaded Files

The FTP 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, a FTP 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 FTP 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.

FTP 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 FTP 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 FTP rather than a Files.com native app, avoid any processing before you know the upload is complete. Avoid implementing Automations, encryption, or Folder Settings on destination folders of FTP uploads because these will act upon partial files.

If you must use Automations on a folder that users upload to via FTP, target the Automation's file name patterns to omit partial uploads or temporary file names (e.g., exclude *.filepart, *.partial, *.tmp). When files are uploaded on a predictable cadence, use schedules to delay actions on uploaded files. For example, if you expect files to be uploaded at 9:00 AM then use an automation with a custom schedule set for 10:00 AM (one hour later), so that you allow an extra hour for any remaining data to be uploaded.