Opening a file with "w" which is already open elsewhere deletes the file's contents and errors

Initially reported: https://github.com/theislab/anndata/issues/522

If I open an hdf5 file in one process (process A) as “r”, then open the same path in another process (process B) as “w” the contents of the file are deleted, process B errors, and an empty file is left in it’s place

Example

Process A

In [1]: import h5py
   ...: f = h5py.File("tmp.h5", "w")
   ...: f["X"] = [1, 2, 3]
   ...: f.close()
   ...: 
   ...: g = h5py.File("tmp.h5")

Process B

In [1]: import h5py
   ...: f = h5py.File("tmp.h5", "w")
---------------------------------------------------------------------------
BlockingIOError                           Traceback (most recent call last)
<ipython-input-1-a87c05b11692> in <module>
      1 import h5py
----> 2 f = h5py.File("tmp.h5", "w")

/usr/local/lib/python3.8/site-packages/h5py/_hl/files.py in __init__(self, name, mode, driver, libver, userblock_size, swmr, rdcc_nslots, rdcc_nbytes, rdcc_w0, track_order, fs_strategy, fs_persist, fs_threshold, **kwds)
    440             with phil:
    441                 fapl = make_fapl(driver, libver, rdcc_nslots, rdcc_nbytes, rdcc_w0, **kwds)
--> 442                 fid = make_fid(name, mode, userblock_size,
    443                                fapl, fcpl=make_fcpl(track_order=track_order, fs_strategy=fs_strategy,
    444                                fs_persist=fs_persist, fs_threshold=fs_threshold),

/usr/local/lib/python3.8/site-packages/h5py/_hl/files.py in make_fid(name, mode, userblock_size, fapl, fcpl, swmr)
    199         fid = h5f.create(name, h5f.ACC_EXCL, fapl=fapl, fcpl=fcpl)
    200     elif mode == 'w':
--> 201         fid = h5f.create(name, h5f.ACC_TRUNC, fapl=fapl, fcpl=fcpl)
    202     elif mode == 'a':
    203         # Open in append mode (read/write).

h5py/_objects.pyx in h5py._objects.with_phil.wrapper()

h5py/_objects.pyx in h5py._objects.with_phil.wrapper()

h5py/h5f.pyx in h5py.h5f.create()

BlockingIOError: [Errno 35] Unable to create file (unable to lock file, errno = 35, error message = 'Resource temporarily unavailable')

In [2]: !cat tmp.h5

In [3]: 

As would be expected, process A cannot read in any data from the file now:

Process A

In [2]: g["X"]
---------------------------------------------------------------------------
KeyError                                  Traceback (most recent call last)
<ipython-input-2-b128f70c4a90> in <module>
----> 1 g["X"]

h5py/_objects.pyx in h5py._objects.with_phil.wrapper()

h5py/_objects.pyx in h5py._objects.with_phil.wrapper()

/usr/local/lib/python3.8/site-packages/h5py/_hl/group.py in __getitem__(self, name)
    286                 raise ValueError("Invalid HDF5 object reference")
    287         else:
--> 288             oid = h5o.open(self.id, self._e(name), lapl=self._lapl)
    289 
    290         otype = h5i.get_type(oid)

h5py/_objects.pyx in h5py._objects.with_phil.wrapper()

h5py/_objects.pyx in h5py._objects.with_phil.wrapper()

h5py/h5o.pyx in h5py.h5o.open()

KeyError: 'Unable to open object (bad local heap signature)

What I was expecting

I would expect h5py to error in Process B before removing the contents of the file. For most other python API’s I would expect Process B to succeed at creating a new file, and then process A to fail when it tried to read anything.

---

Version info

h5py    3.2.1
HDF5    1.12.0
Python  3.8.6 (default, Nov 20 2020, 18:29:40) 
[Clang 12.0.0 (clang-1200.0.32.27)]
sys.platform    darwin
sys.maxsize     9223372036854775807
numpy   1.20.1
cython (built with) 0.29.22
numpy (built against) 1.17.5
HDF5 (built against) 1.12.0

[takluyver]

Sorry, I don’t want to do that: if HDF group want to keep using JIRA as their main issue tracker, it’s just extra noise and confusion to duplicate the issue on Github, and there’s no guarantee it will get any status updates. If they want to shift towards Github issues, I imagine they’ll find some way to systematically copy over open issues from JIRA, which would be better than me copying individual ones.

[epourmal]

Thomas,

Thank you for reporting. I agree that this behavior defeats file locking that was introduced in HDF5 1.10.0 We will look into the problem.

Thank you!