The conformance program
A backend is not done when the code compiles — it is done when a real server has agreed with it. We built the harness that asks.
Most of a storage backend’s cost is not writing the client code; it is discovering how one particular server deviates from the protocol. And the only honest answer to “does backend X work?” is “against which server?”. So the question now has a machine that answers it: a conformance harness that takes any backend, connects to a real server, and runs roughly a hundred and twenty assertions at it.
Every assertion is a bug somebody has shipped. A rename onto an existing
name. A zero-byte file. A write past the end of a file. A filename of 255
bytes where the server meant 255 characters. Two names that
differ only by Unicode normalisation — one entry on the server, or two?
Each case is tagged must (the contract the volume layer relies
on), should (a well-behaved server, a quirk to route around
otherwise) or probe (an observation that becomes capability
data).
The verdicts are not a private scorecard. Each run commits an evidence record — a date and the server’s own version string — and no service is shown as verified here without one, or with one that has gone stale. Eleven lanes are committed today, against real servers: OpenSSH, Samba, MinIO, moto, rclone’s WebDAV server, wsgidav, pyftpdlib, azurite, fake-gcs-server, a folder on disk, and the in-memory reference backend. So when a backend page says verified, there is a file in the repository that says against what, and when.
Being honest about this means saying what the records contain, because it is not a clean sweep. Only the in-memory lane passes all hundred and twenty assertions. Every live lane found something — sixty-two blocking findings across the ten of them on the first run, from an SFTP client that reports “already exists” as a generic I/O error to a WebDAV reader that panics on a server whose listings put a trailing slash on a file. Those are real defects in our code, found by exactly the machine built to find them, and each service now carries its own status and its own list of what is outstanding rather than a single word. A backend that says verified against a live server and has open conformance findings is telling you two true things at once.
Two services on this site say verified against a live server with no conformance record behind them: pCloud and plain HTTP. Their claim rests on their own live test suites and on the ledger’s prose, because neither can have a lane — pCloud has no emulator and no free test account, and HTTP is read-only, so a corpus of read-and-write assertions has nothing to say about it. That is written down in the repository beside the other thirty-four services, and the build refuses to publish a service as verified with neither a record nor a written reason there cannot be one. Twenty-six more services have no record at all and do not claim one; most are commercial clouds that need a real account, and each says which.
A green run against our in-memory backend is the floor, not the ceiling — it proves the corpus is coherent. The live lanes are where the findings live, and each one closed is a changelog entry.