Command reference

snapdir creates content-addressable directory snapshots. The 1.10.0 CLI has a small universal output surface, plus command-specific option families: flags are accepted only by the commands that use them. Put flags after the subcommand, as shown in the examples on each command page.

snapdir [OPTIONS] <COMMAND>

Commands

Command Description
manifest Print the manifest of a directory
id Print the manifest ID of a directory or a manifest piped via stdin
stage Save a snapshot of a directory into the local cache
push Push a snapshot to a store given its path or a staged manifest ID
fetch Fetch a snapshot from a store into the local cache
pull Fetch a snapshot from a store and check it out to the given path
checkout Check out a snapshot to a directory
verify Verify the integrity of a snapshot in a store
verify-cache Verify the integrity of the local cache
flush-cache Flush the local cache
locations List directories and stores where snapshots have been recorded
ancestors List ancestor snapshot IDs and their locations
revisions List snapshot IDs created on a location (store or absolute path)
defaults Print default settings and arguments
sync Copy a snapshot directly between two stores
diff snapdir diff: compare two manifest sides without downloading objects
version Print the version
autocomplete snapdir autocomplete: generate shell completions

Universal options

These output-control flags are accepted by every subcommand.

Option Description
-q, --quiet Suppress stderr banners and the live progress line.
--color <WHEN> When to colorize progress output: auto (default), always, or never.
--no-progress Disable the live progress line. Env: SNAPDIR_NO_PROGRESS.
--verbose Enable verbose output for commands that emit effective-config or cache notices.
-h, --help Print help (see a summary with -h).
-V, --version Print version.

Command-specific options

These flags are attached only to the commands that use them. Passing an inapplicable flag now fails with a clear clap error instead of being ignored.

Family Options Commands
Walk/hash --exclude <PATTERN>, --walk-jobs <N> (SNAPDIR_WALK_JOBS) id, manifest, stage, push
Manifest output --absolute, --no-follow, --checksum-bin <NAME> manifest
Store/cache --store <URI> (SNAPDIR_STORE), --objects-store <URI> (SNAPDIR_OBJECTS_STORE), --cache-dir <DIR> (SNAPDIR_CACHE_DIR), --catalog <NAME> (SNAPDIR_CATALOG) transfer commands, manifest catalog logging, defaults
Transfer tuning -j/--jobs <N>, --limit-rate <RATE>, --adaptive[=<FRACTION>], --max-jobs <N>, --max-retries <N>, --retry-base-ms <MS>, --retry-max-ms <MS>, --max-requests <N> push, fetch, pull, checkout, stage, sync, defaults
Snapshot selection --id <ID> push, fetch, pull, checkout, verify, sync, diff, ancestors
Materialization --linked, --force, --keep, --dryrun, --delete, --exclude <PATTERN> checkout, pull; shared transfer flags may also appear on non-materializing commands
Verification --purge verify, verify-cache
History --location <DIR\|STORE>, --catalog <NAME> locations, revisions, ancestors
Diff --from <REF>, --to <REF>, --all, --json, --exit-code, --on-conflict <POLICY> diff
Completion <SHELL> autocomplete

Linked views and exact mirrors

checkout and pull are additive by default: they materialize the snapshot but leave unrelated files already present in the destination. Add --delete to make the destination an exact mirror of the snapshot. The mirror pass prunes entries that are absent from the manifest, honors repeatable --exclude <PATTERN> protections, supports --dryrun, refuses dangerous destinations such as /, $HOME, the cache directory, and store paths, and unlinks extraneous symlinks rather than following them.

--linked is the read-only local materialization mode for checkout and pull: destination files are symlinks into local content-addressed objects hardened to mode 0444. It is zero-copy and useful for local read-only views, but it requires local objects; a remote object store is a hard error with --linked. The flag may appear in the shared transfer option group for other commands, but those commands do not create linked checkouts.

Catalog behavior

The default catalog is enabled when --catalog is unset. stage, push, and manifest can record locations there, and locations, revisions, and ancestors read from it. Pass --catalog none to disable catalog writes or queries explicitly; query commands then report that the catalog is disabled.

Environment variables

The full set of SNAPDIR_* variables commonly used by the CLI:

Variable Equivalent option
SNAPDIR_CACHE_DIR --cache-dir
SNAPDIR_CATALOG --catalog; unset uses the default catalog, --catalog none disables catalog writes and queries
SNAPDIR_STORE --store
SNAPDIR_OBJECTS_STORE --objects-store
SNAPDIR_NO_PROGRESS --no-progress
SNAPDIR_WALK_JOBS --walk-jobs
SNAPDIR_JOBS -j, --jobs
SNAPDIR_LIMIT_RATE --limit-rate
SNAPDIR_ADAPTIVE --adaptive
SNAPDIR_MAX_JOBS --max-jobs
SNAPDIR_CLONEFILE Set 0 to disable copy-on-write clone/reflink fast paths.
SNAPDIR_VERIFY_COPIES Set 1 to force write-time re-hash even on clone fast paths.
SNAPDIR_FSYNC batch (default) or off for accelerated SSH receive-pack durability.
SNAPDIR_SSH_ZSTD_LEVEL Zstd level for SNAPPACK 1Z SSH acceleration.

Run snapdir defaults to print the effective settings, including each resolved value and whether it came from a flag, env var, or default.

Retries & backoff

On transient failures — HTTP 429/503, S3 SlowDown, GCS RESOURCE_EXHAUSTED, and network timeouts — snapdir retries the request with full-jitter exponential backoff (--max-retries / --retry-base-ms / --retry-max-ms). When the server sends a Retry-After header, snapdir honors it as a floor: it never retries sooner than the server asked, but may wait longer if the jittered backoff is larger. Non-transient errors — 404, 403, missing objects, or bad credentials — fail fast without retrying. The storage SDKs' own retry logic is disabled, so this is the single retry policy for every backend. The per-backend request and bandwidth caps, --max-requests, and --limit-rate are covered in the Stores guide.

Stores

The --store URI selects a backend by scheme. Four schemes are served by built-in, in-process adapters; any other scheme dispatches to a snapdir-<scheme>-store shim on PATHssh:// and sftp:// ship as two such first-party shims (cargo install snapdir-ssh-store provides both):

Scheme Backend
file:// Local filesystem
s3:// Amazon S3 (and S3-compatible)
gs:// Google Cloud Storage
b2:// Backblaze B2
ssh:// Any host with SSH shell access (system OpenSSH client)
sftp:// Any SFTP server, incl. restricted/chroot accounts (system OpenSSH client)

See Stores and cache and the Stores guide for details.

See also