Skip to main content

File Expiration

File Expiration deletes files in a folder that have not been modified within a specified number of days. Use it to enforce retention rules, control storage growth, and keep sensitive data from lingering past its useful life.

Configuring File Expiration

You configure File Expiration on a per-folder basis. Site Administrators, Workspace Administrators, and users with administrator access to a folder can configure expiration settings. Workspace Administrators can only configure it on folders within their Workspace. To enable expiration, supply the folder path and the number of days files are kept before they are automatically deleted. You can also choose to apply the rule only to the files directly in the folder, not to its subfolders.

By default, File Expiration removes only files and leaves the folder structure intact. You can also configure it to remove empty folders.

Delete Empty Folders

The Delete Empty Folders option removes folders that become empty after their files expire. It also removes folders that were already empty before expiration ran.

This option is only available when the rule applies to subfolders.

Delete Empty Folders does not remove a folder that has permissions, folder settings, or notifications applied directly to it.

Overriding the Setting in Subfolders

By default, a folder's File Expiration setting also applies to its subfolders. You can override this behavior in two ways.

The first is to mark a folder's expiration setting to not apply to subfolders.

The other is to configure a separate File Expiration setting for a subfolder path. The subfolder's setting can specify a different number of days, or disable expiration entirely with Never delete files in this folder. When Root Folder Settings protect an inherited site-root rule, only a Site Administrator can create, change, or remove that disable exception. Administrators of the subfolder can still set a different number of days.

Deletion Timing

File Expiration settings apply to all files retroactively. If you have files older than the time frame you choose, those files begin to be deleted within 24 hours of updating the setting.

Deletion of expired files runs once per day. The age of each file in the affected folder and its subfolders is checked, and files older than the specified retention period are deleted. How long the process takes depends on how many files are being deleted and whether subfolders are included.

Retaining Deleted Files

File Expiration removes active files after a specified interval. A separate setting controls how long deleted files are retained as backups eligible for restore. See Retaining Deleted Files for details.

Site Administrators can restore retained files using the Restore Deleted Files feature.

Remote Mounted Folders

File Expiration works on folders backed by a Remote Server Mount, including Agent, Azure Blob, Google Cloud Storage, S3, and the other remote storage types. Files past the expiration age are deleted directly from the remote storage, and the folder structure stays intact, the same as on native Files.com storage.

A Remote Server Mount is a boundary for File Expiration, the way a Permission Fence is a boundary for permissions. A mount does not inherit a File Expiration setting from a folder above it in the hierarchy. To expire files on a mounted folder, set File Expiration directly on the mount, or on a folder within it.

Logging

When Files.com performs its automated File Expiration sweeps, the resulting deletions are recorded in the history logs the same as any other deletion. The logs show the deletion was performed by the user "robot".

Changing the Setting on the Root Folder

When File Expiration is set on the site's root folder, Root Folder Settings can allow only Site Administrators to change it. Folder admins can still see the setting but cannot change it.

Applying the Setting in Every Workspace

When File Expiration is set on the site's root folder, Root Folder Settings can extend its inheritance into every Workspace on the site, including Workspaces created later. If the root rule applies to subfolders, it covers existing and new files wherever a more specific rule or disable exception does not take precedence. Deletion follows the normal schedule.

Workspace Administrators can set a different expiration period on their Workspace's root folder or any folder within it, including a longer period than the site-root rule. This lets a workflow keep files for the period it needs without changing retention for other Workspaces. That local rule takes precedence within its scope. Choosing Never delete files in this folder to switch off inherited site-root expiration requires a Site Administrator, as does changing or removing that exception.

Adding the Setting to Every Child Site

A Child Site Management Policy can add File Expiration to the root folder of every Child Site it covers. While the setting is part of a policy, nobody on the Child Site can change it.