Atomic Uploads

Files.com treats file uploads as atomic operations. A file must be uploaded completely before it appears in file listings and becomes available to work with.

Atomicity prevents files from being accessed in an incomplete state and preserves file integrity for automated processes like webhooks, GPG encryption, Automations, and Syncs.

Any attempt to access a file before the upload has completed will fail as if the file does not exist. When an existing file is being changed, downloading it during the change returns the previous, unchanged version.

Atomicity is maintained when you use the Files.com web interface and Files.com's native apps, including the Command Line App (CLI), Desktop App for Windows/Mac, Mobile app for iOS/Android, and SDKs for developers. The same guarantee does not extend to file transfers performed using third-party apps such as FTP clients.

To ensure atomic uploads, use Files.com native apps wherever possible.

Third-Party Client Apps

Third-party FTP, SFTP, and WebDAV client apps do 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. Implementations differ from client to client, so the server cannot 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 is treated as partial. However, some popular FTP clients, most notably FileZilla, do not send the ABOR command when a transfer is cancelled. The server then treats the received partial file as a complete file.

Remote Mounts

Atomic uploads are limited by the storage solution behind a Remote Mount. 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, leaving a partial or incomplete file on the remote system.