Google Cloud’s object store, and the backend of many a data pipeline.

Emulator-tested Tested against an emulator

What Mountit does with it

Mount

Read and write, in Finder

Offline cache

Metadata cache, read-ahead and write-back — the same volume stack as every other service

Encryption layer

Available on this connection: client-side, rclone-compatible crypt over the data before it leaves your Mac

Editions

Both. Either edition mounts it through File Provider, so it appears in Finder — and, on Standard, in the Files app on iPad and Vision Pro

Limits

What Google Cloud Storage cannot do, read from the app's own service_traits() — the same answer its connection picker shows before you connect, not a judgement typed onto this page.

Prefixes, not directories

There are no real directories in this store — a “folder” is a shared prefix on the object keys. Making one writes a zero-byte marker object so the empty folder you just created is still there when you look again; a folder that only ever existed because files were under it has no marker, and goes when its last file goes. Anything that depends on an empty directory persisting has to know that.

A move is a copy, then a delete

This service has no server-side rename, so renaming or moving a file copies the bytes to the new name and only then deletes the old one — that order, so an interrupted move leaves your file where it was rather than nowhere. What it costs is a full transfer of the bytes, which is worth knowing before you drag a large folder. On this store a folder move is refused as a single operation and done file by file, because moving the one key that names the folder would leave everything under it orphaned.

The engineering ledger lists Google Cloud Storage among the services run against a real server. Which of those two things it says is read out of docs/BACKEND-COVERAGE.md in the app repository when this site is built, not typed here — so the level above moves when the ledger does, and the build stops rather than leave the paragraph above it saying something else.

The conformance record

Blocked by a finding. A lane ran and 13 findings stand between this service and a clean record. They are the return on running the corpus, and they are published rather than filtered. Every service’s standing, side by side.

Being mounted once is the floor. The conformance harness runs the same corpus of assertions at every backend — must for the contract the volume layer relies on, should for a well-behaved server, and probe for observations that become capability data — and commits the verdicts as a file. These numbers are read out of that file.

A failure here is a finding about this protocol, not a broken test. They are published rather than filtered because a page that showed only the green ones would be worth nothing.

• fake-gcs — 123 assertions. 13 assertions tagged must failed. 2 capabilities the backend claimed were contradicted by what the server actually did. On the harness's own rule — no must failure and no capability disproved — this lane does not by itself promote the service.

Google Cloud Storage questions