File Operations

Renaming a folder or copying a file on a Remote Server Mount can require much more work than the same command suggests on a local drive. Files.com translates the action into operations supported by the connection: a remote rename, a provider-side copy, a read followed by an upload, or work on each file in a tree. Those differences determine how long the operation takes, what access it needs, and what people and applications can use while it runs.

A completed operation puts the file or folder at the requested path. The work needed to produce that result depends on the connector, source and destination locations, existing destination files, and required file processing. A successful small-file upload does not establish the cost or completion behavior of a large folder move.

Copies and File Renames Within One Mount

For an ordinary file copied within the same mount, Files.com uses the connector's copy operation. A provider-side copy asks the remote service to create the destination from content it already holds. A streamed copy reads the contents and uploads them to the destination. Both create a new file at the destination, but only the latter requires that read-and-upload transfer through Files.com or the configured Agent.

The table describes individual file operations within one mount, without destination processing. Existing destination files have separate replacement behavior. Remote permissions, service boundaries, and provider limits still determine whether a requested operation succeeds.

The S3-compatible row includes Backblaze B2, Cloudflare R2, Filebase, Akamai Linode, and Wasabi connections. Connecting to a service through FTP or SFTP instead uses that protocol's behavior, even if the service offers its own copy interface. For example, Egnyte and ShareFile use their configured file-transfer protocols.

An S3 copy is an object operation inside S3, not a download followed by an upload through Files.com. The destination is a new object referencing the copied content; a rename then removes the original object from the current view. This is distinct from FTP or SFTP copying, which transfers the complete file contents. The logical copy still has S3's request, metadata, versioning, and billing consequences.

Provider-side operations can still take time, require several requests, or fail. Files.com follows the remote operation's result, including completion of supported asynchronous copies. A service's support for a native operation does not mean every Files.com action uses it: Azure Files moves use copy and delete, and a folder move can require processing its children even when individual files support native rename.

Moves, Renames, and Folder Trees

A rename changes the destination path, so it follows move behavior. Where the connector uses copy and delete, Files.com completes the copy before attempting to remove the source. These are separate remote operations. Between them both paths can exist; if deletion fails, both can remain.

On flat object storage, a folder name is part of every object's name. Renaming Incoming/Batch to Ready/Batch therefore changes the paths of its files, rather than just changing a directory label. Files.com processes the tree, creates the destination folders as needed, performs the individual file operations, and removes source folders as the move completes.

A tree operation is not one transaction. Some files can reach the destination while others remain at the source or fail. A destination folder's appearance does not establish that all its children have arrived. This applies beyond object storage: do not assume a folder rename is one native directory operation merely because that connection supports native file renames.

For a large tree, the number of files matters as well as total size. Many small objects require many listings and file operations. A provider-side copy avoids relaying the contents, but it does not remove the per-object work. A streamed copy also depends on the time needed to read and write the contents.

Moving between separate mounts or between native and remote storage changes the operation's boundaries. The move requires a destination write followed by source deletion, rather than one remote rename. Two mounts pointing to the same provider do not by themselves make this a provider-side move. A Sync is also a transfer between its configured locations; its transfer path is separate from the same-mount copy behavior above.

For applications that use a final rename as a signal that a delivery is ready, choose a handoff supported by the actual connection. A copy-and-delete rename is not an atomic change, and a folder can become visible incrementally. Keep the receiving application from consuming that destination until the required files have completed, or use a completed-file handoff with semantics the application supports.

Replacement of Existing Files

A requested copy or move normally leaves an existing destination file in place unless overwriting is enabled. With overwriting enabled, Files.com deletes the destination before replacing it. The connection needs delete access at the destination as well as the access required for the replacement.

That sequence creates an availability gap: the previous destination is gone before the new one is complete. If the replacement fails, Files.com does not roll back the deletion as part of the copy or move. Recovery depends on the remote system's versioning, soft delete, or backup configuration. A successful provider-side copy optimization does not change this preceding deletion.

Uploading directly to an existing filename uses the connection's upload behavior instead. It normally replaces the contents without a separate delete. Some FTP and SFTP servers require delete-and-recreate handling, so an upload that creates a new name can succeed while replacement fails. A Sync normally uses this upload behavior, whereas a copy or move Automation follows the copy or move overwrite sequence.

Upload completion and visibility also depend on the destination. Atomic Uploads explains the remote-storage boundary. FTP and SFTP connections offer remote staging so a file can upload outside the application's pickup folder and move into place after completion. The final move still depends on the server's permissions and rename behavior.

Resuming an upload is another place where familiar file operations can require extra work. Where the destination cannot write directly at the requested position, Files.com can read the existing prefix and write it into a replacement before accepting the remaining contents. The bytes sent by the client after a restart therefore need not represent all the data read or written remotely.

Time and Usage

Estimate a large operation from the work it performs, rather than its number of commands. Relevant costs include provider requests for listings, metadata, copies, uploads, and deletions; retrieval or network charges when contents are read or transferred; and storage for new objects and retained prior versions. The provider's rates and storage class determine which charges apply.

Files.com Transfer Usage depends on the actual contents transferred through Files.com's network. A provider-side copy is different from a relayed read and upload. A streamed copy can transfer a complete file in both directions even when the user has only selected Copy within one remote folder. Direct Routing for an eligible client download does not establish that a subsequent server-to-server copy uses the same route.

Buffered Uploads and required file processing can add temporary native storage and onward transfer. GPG processing or Auto Unzip at the destination changes the file-delivery path even when a simple unprocessed copy on that connector could stay within the provider. Review Folder Settings Within Remote Server Mount before estimating that workflow.

Remote service rate limits and connection limits affect all work using that endpoint. More parallel operations can exhaust the provider's capacity or delay other Mounts, Syncs, and applications. A higher connection setting is useful only when the remote system can sustain it.

Large Operations and Recovery

Before reorganizing working remote storage, establish the result with a representative folder outside live pickup paths. Include existing destination names, the required processing, and the same connection identity. Test the requested copy, move, or replacement itself; a new-file upload tests a different operation.

For an operation that can interrupt active work, coordinate with the people and applications using both paths. Keep source contents stable, allow for the destination to appear incrementally, and establish how earlier contents can be recovered. Copying first and validating the destination before deleting the source can separate the transfer from the final cutover when the workflow permits it. A Files.com direct Move also updates associated links and configuration, while a separate Copy and Delete does not; the migration guidance explains that choice.

Review the operation's complete result and failures before treating the destination as ready. For one-time work, the web interface provides progress; for a recurring job, use its run results. The Outbound Connections log helps identify remote failures, while the provider's records explain work performed there.

After an interruption or failure, inspect both locations before repeating or deleting anything. Completed files can remain at the destination, source files can remain after a failed delete, and an overwritten destination can already be gone. Retries do not make the whole tree an indivisible operation or restore its previous state. Reconcile the affected paths and recovery options before another broad overwrite or move.

Remote versioning and retention can preserve earlier contents after current files move or disappear. Those retained copies can continue to use provider storage. Moving the visible files does not permanently remove their prior versions; Object Storage Behavior explains that distinction.