Addressing
How a URI scheme maps to a backend, and the built-in schemes.
Every remote is a named entry in config whose name is the URI scheme; its
type selects the backend. So if you name an S3 remote aws, you address it as
aws://bucket/key.
A handful of schemes are built in and need no configuration:
| Form | Meaning |
|---|---|
./a, /tmp/b | bare path — the local filesystem |
file:///abs/p | local filesystem (explicit) |
local://<alias>/path | a configured local folder, sandboxed to its base dir |
mem://vol/path | ephemeral in-memory volume (tests / smoke checks) |
<remote>://… | a named remote from config (s3, bunnystorage, bunnystream, …) |
http://…, https://… | read-only HTTP(S) source |
zip://<a>.zip/<inner>, tar://<a>/<inner> | read-only view inside a local archive |
- | stdin (as cp source) / stdout (as cp destination) |
Bucket-style remotes
For object stores the first path segment is the bucket:
dumont ls aws://my-bucket/path/to/dir
# └ remote └ bucket └ key prefixA bucket is required for S3 remotes — aws:// alone is an error that tells you
so.
Cross-store operations
Because every location resolves to the same vfs.FileSystem interface, the
source and destination of cp/mv/sync can be on different backends. dumont
streams the bytes between them:
dumont cp aws://bucket/report.csv drive://reports/
dumont sync ./site cdn://www --delete
dumont cat zip://release.zip/CHANGELOG.mdLocal folder aliases
local://<alias>/path resolves an alias from the local_folders config map to
a base directory, and sandboxes access to that directory — symlinks that try
to escape the base are contained. See Configuration.