Josh Moore

> is there some low-effort solution with current v2? I think so, yes. This sounds very much like a straight-forward bug (thanks for opening as #1121). Somewhere there's a check...

Thanks for the suggestion, @elfring. Are you up for opening the PR?

A PR with these changes would be fine, yes.

Hi @christophenoel you probably want to look at the methods in zarr/core.py: ``` _get_selection \_ _chunk_getitem \_ _chunk_key ```

Hi @camFoltz. I don't know of a zarr-specific mechanism for recording the read-only setting. As a workaround, have you looked at making it read-only at the underlying storage level?

@clbarnes : *nods* and I seem to remember a store (`FSStore`) recently switching its local default. I'll try to find that commit/PR. Edit: https://github.com/zarr-developers/zarr-python/pull/546#discussion_r410047224

This issue may be fixed by https://github.com/zarr-developers/zarr-python/pull/916

@hailiangzhang, interesting. I can definitely understand your surprise. Reading https://zarr.readthedocs.io/en/stable/api/core.html?highlight=resize#zarr.core.Array.resize, however, it's only clear (at least for me) that out-of-bound chunks are removed not that the in-bound chunk is re-written....

:+1: for the doc improvement. I've updated the title of this issue to: * `resize(): Improve docs & control of what is modified` with the control being potential new arguments,...

Happy to leave that up to you. If you think new method arguments are worth it, feel free to leave open. Otherwise, feel free to close.