Asynchronous (Backgrounded) Operations

Large or complex operations on files are sometimes performed asynchronously. Examples include copying files, moving files from Files Native Storage to a Remote Server, moving files on or between Remote Servers, renaming files or folders on Remote Servers, and deleting folders on Remote Servers. Any copy, move, or delete operation can potentially run asynchronously. We are constantly optimizing our platform and its services, so the set of operations that can run asynchronously is always evolving.

Asynchronous operations improve performance and make features on remote mounts behave similarly to locally attached storage.

An asynchronous operation can be triggered from any connection type, including the web portal, any protocol connection (FTP, SFTP, etc.), the REST APIs, and our SDKs.

Web Portal

When a file migration runs in the background, a Processing message confirms that it is running. Status information appears in the web portal UI under a dropdown labeled Actions In Progress. If an operation remains in Actions In Progress for an unexpectedly long time, contact Files.com support. If you triggered the operation through the REST API or an SDK, include the FileMigration ID from the API response so support can investigate the specific operation.

API

When the REST API returns a pending status, it includes a FileMigration ID. Use that ID to query the migration's status. The background path update after a native folder move has no FileMigration ID.

Folder Moves on Files.com Storage

When you move or rename a folder within Files Native Storage, the folder itself moves immediately and the API reports completed. Files.com then updates the paths of the files and subfolders inside it in the background. The time required depends on how many items the folder contains, so the folder operation can finish before its contents are available at their new paths.

The background update also adjusts the paths associated with folder permissions, email notifications, Share Links, per-folder branding, and priority colors so they follow the moved content. User root and home folder paths that point to the moved folder or a location inside it are updated too.

Until an item's path has been updated, it remains available at its previous path and may not be found at its new path. This behavior applies across users, API keys, and interfaces. Requests using a previous path are checked against the permissions for that path, just as before the move; the background update does not grant access that those permissions did not already allow.

Moving or renaming a folder is not a way to revoke access. To end a user's access, remove the permissions that grant it, including any applicable group or inherited permissions.

This path update is separate from a file migration and has no ID or completion status to query. Before a script or another process uses the moved contents, verify that the files it needs are available at their new paths.

Operation Record Retention

File migration records track background operations such as copies, moves, and deletes. Files.com retains a completed operation's record and logs for 72 hours after its final activity. This includes operations that ended in failure or were canceled. An operation that never completes is removed after 30 days without activity, measured from its last activity rather than its creation time.

Once the record is removed, its FileMigration ID no longer provides status or log details. Removing the record does not reverse the operation or delete files it created. File actions remain subject to the separate History Log retention period.

SDK

Some of our SDKs manage the asynchronous operation and present it as a synchronous operation. We are extending this capability to all our SDKs, including those used by our iPaaS partner connectors.

Desktop Apps

The Files.com Desktop app, Mobile app, and third-party client apps are unaware of asynchronous background operations and reflect the current view of files and folders. Once the asynchronous operations complete, refreshing reflects the updated file and folder view.

Scripts and Integrations

Protocol clients are also unaware of asynchronous background operations. For example, using the SFTP rename command to move a file from one Files.com storage region to another, or from one Remote Server Mount to another, starts a background process to move the file. Control returns to the SFTP client immediately, even though the move is still occurring in the background.

If a script or iPaaS process makes the connection, the next commands run while the move is still in progress. If your script, or process, immediately tries to access the moved file then it will fail because the move operation hasn't completed yet.

A reliable integration with Files.com accounts for these asynchronous background operations. Build verification steps into your scripts and processes that confirm a moved, renamed, or copied file is available at the destination before taking any further action on it.

Sessions

For a file migration, Files.com can hide the source of a background move or deletion from the session that started it. This keeps that session's view consistent with the requested action while the underlying work continues. Other sessions may still show the source while the operation is running, so a source disappearing from your listing does not confirm that the operation has finished. Check the migration's status or verify the destination before another process uses the result.