Skip to content

fix: refuse writes to a store zarr-python opened read-only - #190

Open
selmanozleyen wants to merge 1 commit into
zarrs:mainfrom
selmanozleyen:fix/respect-read-only
Open

fix: refuse writes to a store zarr-python opened read-only#190
selmanozleyen wants to merge 1 commit into
zarrs:mainfrom
selmanozleyen:fix/respect-read-only

Conversation

@selmanozleyen

Copy link
Copy Markdown
Contributor

Hi,

I'd like to propose some changes for the integer indexing case but because shard index caching depends on it and because it's also a nice thing to have in general I opened this PR. This enables us to be clear with the refusal of writing read only stores.

The flag has to be carried from Python because nothing on the Rust side can infer it: the mode is zarr-python's, not the store's. One guard, at the only entry point Python can write through. store_chunk_bytes and store_chunk_subset_bytes are reached only from it.

zarr-python enforces read-only in the store itself -- `Store._check_writable`, reached from
the concrete store's `_set`. This pipeline never gets there: it is handed a `StoreConfig` and
builds its own Rust store, writable whatever mode the array was opened in, so a write to a
`mode="r"` array succeeds here and raises through the default pipeline. Silent divergence,
and silent data loss for anyone relying on the mode.

The flag has to be carried from Python because nothing on the Rust side can infer it: the
mode is zarr-python's, not the store's.

One guard, at the only entry point Python can write through. `store_chunk_bytes` and
`store_chunk_subset_bytes` are reached only from it.

The tests open STRICT. zarr's own refusal message is byte-identical to the guard's, so with a
fallback available they would pass whether the guard fired or zarr-python served the write.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant