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 default —
cp/mv/syncstream 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 returnErrNotSupported, 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
- Getting Started — build it and copy your first file.
- Addressing — how a URI scheme maps to a backend.
- Backends — the capability matrix and a page per store.
- Commands — every verb and its flags.