Files.com treats file uploads as atomic operations. In other words, a file must be uploaded to Files.com completely before the file will be shown in file listings and available to work with.

This approach is necessary to ensure that a file is never accessed when in an incomplete state, and that file integrity is maintained with automated processes like webhooks, GPG encryption, Automations, and Remote Server Syncs.

This means that any attempts to access a file before the upload has completed will fail as if the file does not exist. If an existing file is being changed, downloading it during a change will result in the previous, unchanged version of the file being downloaded.

While file upload atomicity will be maintained when using the Files.com web interface and Files.com's native apps like our Command Line App (CLI), Desktop App for Windows/Mac, Mobile app for iOS/Android, and SDKs for developers, we cannot guarantee the same for file transfers performed using third party apps such as FTP client apps.

To ensure atomic uploads, we strongly recommend using Files.com native apps wherever possible.

3rd Party Client Apps

3rd party FTP, SFTP, and WebDAV client apps are known to not provide atomic uploads.

These client apps are often designed to leave partial files uploaded in anticipation of resuming the rest of the upload later. Unfortunately, implementations differ from client to client causing the server to be unable to determine whether an uploaded file is partial or complete.

For example, the FTP protocol provides the ABOR client command which tells the server that the client app has cancelled (aborted) an upload. Any received data should be considered partial. However, some popular FTP client apps, most notably FileZilla, will not send the ABOR command when a transfer is cancelled. This tells the server that the received partial file is a complete file instead.

Remote Mounts

The ability to treat uploads as atomic is limited by the storage solution being used to upload into when using the Remote Mount feature. For example, when using FTP or SFTP to connect to a Remote Server, a network disruption between Files.com and the remote system can cause atomic uploads to fail, resulting in a partial or incomplete file being uploaded to the remote system.