dumont
Backends

Backends

The capability matrix and a page per store.

Each backend implements one vfs.FileSystem interface and advertises exactly what it can do via Caps. Operations a backend can't perform correctly return ErrNotSupported — never a silent no-op.

BackendAddressReadWriteDirsNotes
memmem://vol/pathrealin-memory reference impl; ephemeral per process
local./p, file://, local://alias/prealaliases are sandboxed to a base dir (symlink-contained)
s3<remote>://bucket/keysynthAWS S3, R2, MinIO, GCS-interop; multipart + ranged GET
bunnystorage<remote>://pathsynthBunny Edge Storage over HTTP — live-verified
bunnystream<remote>://coll/title~realBunny Stream video API; lossy projection
http(s)https://host/pathread-only source; ranged ReadAt when supported
zipzip://a.zip/innersynthread-only view inside a local ZIP
tartar://a/innersynthread-only; .tar, .tar.gz, .tgz

"synth" = directories synthesized from key prefixes (object-store style). gdrive and a webdav:// backend are planned.

Reading the matrix

  • Read / Write — whether the backend supports reading and writing object contents. ~ means a lossy or best-effort projection (see bunnystream).
  • Dirsreal directories exist as first-class entries; synth means directories are synthesized from common key prefixes, as object stores do.

Emulation makes object stores feel like filesystems

Object stores replace whole objects — they have no native random write, append, or in-place truncate. Wrapping one with the emulate.RMW decorator (emulate: true in config) adds those via read-modify-write: stage the object locally, apply the writes, re-upload on close. It's correct but non-atomic and O(filesize), so it's opt-in and clearly labelled.

On this page