Trash, History & Rollback

Every change to a file is timestamped, and you can always roll back to an earlier point in time. This page covers the lightweight, per-entry mechanism for that: trash and per-file history. For the multi-file, atomic changeset-and-checkout system, see Version Control - that's a different, heavier tool for coordinating a whole set of changes together, not a replacement for this one.

Trash#

Deleting a file doesn't remove it immediately. It soft-deletes into a per-user trash, visible under the project's Trash tab in the web dashboard (open the project, then Trash in its tab strip). There is no cross-project trash view - each project's trash is its own.

You can delete from either place - your file manager (Finder, Explorer, or the command line, on the mounted drive) or the web dashboard. Both do the same thing: the file goes to trash, not away. Deleting a folder takes its contents with it. The dashboard does that in one step; your file manager removes the files inside one at a time and the folder last.

Restoring a folder brings back the folder and everything that was deleted with it in the same step. A folder deleted from your file manager went one file at a time, though, so when you restore it, the web dashboard lists the files that were deleted inside it just before it and asks whether to restore them too. It asks rather than restoring them automatically, because a file you deleted on purpose a moment earlier looks the same.

Retention is per-user, not just per-org: your own account setting, if you've set one, wins; otherwise it falls back to the org's default; otherwise a global 90-day default applies. Set your own under Settings → Account → Trash & history retention (1 to 3650 days), or clear it there to go back to the organization's window. An org's default retention window is settable anywhere from 1 to 3650 days and controls how long a deleted file stays recoverable before it's permanently purged, for anyone in the org who hasn't set their own override. Until that window elapses, restoring a file from trash brings it back in place, at its original path. Retention windows are applied by a daily cleanup, so a change takes effect at the next daily pass rather than instantly.

From the CLI, swarmfile trash list shows your own soft-deleted entries, swarmfile trash restore <entry-id> brings one back (add --with-nearby to also bring back what was deleted inside a folder just before it), and swarmfile trash purge <entry-id> deletes it permanently - "Delete Forever," ahead of the retention window, not recoverable. --preview on purge reports how many descendants a folder would take with it before you commit to removing anything. Because it can't be undone, purge asks for confirmation first; --yes skips the prompt (a non-interactive shell or --json needs it). A very large folder restore or purge runs as a durable background job rather than an inline cascade: the command waits for it by default, and Ctrl-C or --no-wait detaches with exit 3, followed with swarmfile op status / op wait (long operations). op status shows the job's done/total progress while it runs, and in the dashboard the same operation shows progress on the row's own button - a restored folder reappears at once, with its contents filling in behind it.

History and rollback#

Because every change is timestamped, a file's full edit history is available at any time, and you can roll back to any point in that history - not just the most recent save. This is scoped to a single entry: rolling back a file doesn't touch anything else in the project.

Every saved version vs. named commits#

New projects start on Keep every saved version: each automatic save stays restorable, so any point in a file's history can be brought back - not just its named commits. If you'd rather keep storage leaner - on a busy, high-save-volume project, say - choose Named commits only when creating the project, or switch later in the project's settings (or with swarmfile project set-keep-full-history false): individual save versions then expire after the retention window, and committed changesets are kept for that same window - tag one to keep it indefinitely (Keep every saved version keeps everything). The setting is per project, not per file; an org owner can change which choice new projects start with under Settings → Organization (which applies only to projects created afterwards).

When history is kept for less time#

On a project set to Named commits only, a file's history is kept for your retention window, with one exception: if a project's stored file information grows very large (millions of files and versions), Swarmfile automatically keeps history for less time - never below a minimum of 7 days by default - so the project stays under its storage limit. It returns to the full window once the project is comfortably below that point again. Org owners and admins can see the window currently in force, and why, on the project's Project settings tab. See Project storage limit.

Trash and history vs. version control#

Trash and history operate one entry at a time, with no concept of grouping changes across files. If you need to restore a whole folder or project to how it looked before a coordinated set of changes - a batch of asset updates that need to move together, for example - that's what the changeset/checkout system in Version Control is for.