Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mode=r+: Cannot write to read-only ZArray #75

Open
tbenst opened this issue Dec 14, 2021 · 2 comments
Open

mode=r+: Cannot write to read-only ZArray #75

tbenst opened this issue Dec 14, 2021 · 2 comments

Comments

@tbenst
Copy link

tbenst commented Dec 14, 2021

This fails:

p = "/tmp/example.zarr"
z1 = zcreate(Int, 10000, 10000, path = p, chunks = (1000, 1000))
z1[1, :] = 1:10000
mode = "r+"
z2 = zopen(p,mode)
z2[1,2] = 42
z1[1,1:3]

This also fails for mode="a" or mode="a+", but works on mode="w". Unfortunately, I cannot use mode="w" as I do not wish to truncate the file, but rather re-open an existing Zarr array for modification. On testing, it appears that mode="w" does not actually truncate the .zarr directory, which I believe conflicts with julia's definition for open modes / is inconsistent with python Zarr.

Much appreciate your efforts to bring Zarr to Julia!

@meggart
Copy link
Collaborator

meggart commented Dec 14, 2021

Sorry for this, this is definitely bad documentation/implementation. Mode "w" does not truncate but is actually equivalent to "a". When originally implementing this I was following the mental model of NetCDF modes and only made a difference between Read-only and Read/Write modes and just called them "r" and "w" without thinking a lot.

Yes, we should fix this, but this will be breaking in a very nasty way, when silently changing the behavior of "w" to actually truncate the file while in the past it meant "append". So I would suggest to have a full deprecation cycle on this... Will think about it a bit, but please suggest solutions in case you have ideas.

@tbenst
Copy link
Author

tbenst commented Dec 14, 2021

Ah, thank you! Good to know that I can use “w” for now. Full deprecation cycle makes sense, and perhaps useful to add “a” as an alias in meantime

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

No branches or pull requests

2 participants