dumont

Introduction

One filesystem over local disk, object stores, Google Drive, archives, and HTTP — driven from the command line.

dumont puts one filesystem abstraction in front of every store. The same handful of verbs — cp, mv, ls, sync, cat, stat, rm — work everywhere, and data flows between unlike stores with a single command.

dumont cp aws://bucket/report.csv  mydrive://reports/   # copy between unlike stores, one verb
dumont sync ./site  cdn://www --delete                  # one-way incremental mirror
dumont cat zip:///releases/v2.zip/CHANGELOG.md          # peek inside an archive

"All that is visible must grow beyond itself, and extend into the realm of the invisible." — Dumont, keeper of the I/O Tower

The name is a nod to Tron's Dumont, guardian of the I/O Tower — the gateway through which Programs reach the world beyond the Grid. dumont is that gateway for your data: every storage system is its own walled world, and dumont is the one honest door between them.

Why

Every storage system speaks its own dialect — S3 multipart, Drive file IDs, Bunny zones, tar offsets, HTTP ranges. dumont hides those behind a single vfs.FileSystem, so you stop learning per-tool CLIs and start moving data.

Its guiding rule: be honest. A backend advertises exactly what it can do, and an operation it can't perform correctly fails loudly with a typed error — it is never silently emulated in a way that corrupts data. Emulation (e.g. read-modify-write for random writes on object stores) is opt-in and clearly labelled non-atomic.

Highlights

  • One filesystem, many stores — local disk, S3-compatible, Bunny Storage/Stream, ZIP/tar, HTTP, all behind one interface.
  • Cross-store by defaultcp/mv/sync stream directly between any two backends.
  • Incremental sync — one-way mirror that copies only what changed; --delete, --dry-run, idempotent.
  • Honest capabilities — each backend declares its Caps; unsupported ops return ErrNotSupported, never a silent no-op.
  • Composable decorators — a transparent metadata cache, plus opt-in read-modify-write to add random writes over object stores.
  • Conformance-tested — one behavioral battery every backend must pass.
  • Secrets never inline — credentials are env: / file: / keychain: references resolved on first use.
  • Single binary, pure Go — no CGo, no daemon, no mounts.

Where to next

On this page