I’ve just taken over a project (VS2019, .NET 472) which uses HDF5.Pinvoke version 1.8.20.
The application and unit tests work fine. The application for example exports data to a file, let’s say ‘test.h5’. If I export to the same file then the file is overwritten and works fine.
If I update to HDF5.Pinvoke version 1.10.6.1 (or 1.10.612) simple changes to the code are required since the api return values are now mostly ‘long’ in place of ‘int’. However if I now export to the same file twice, the second time the app fails because the original ‘test.h5’ is still being held open until I close the application and restart.
Similarly unit tests which repeatedly create, close, delete the same test file now fail because the file is being held open.
Is this a bug in HDF5? Or Is it because our code isn’t closing all sub-objects within the file correctly?
Assuming it’s a bug in our code is there a way to log which if any objects are still open when H5F.close is called?
As Gerd mentions, it’s more idiomatic to use an hid_t type for HDF5 library IDs instead of the underlying representation directly (i.e. an integer). Even though the compiler won’t complain, a library ID is really a bunch of packed bits and doesn’t have “number” semantics.
I’m completely new to HDF. I did notice that 1.10 seems to give more diagnostics info when running. It did helpfuly show that the code was unable to close a group (because I was passing in a int). It would have been useful to see the value of the id it was having trouble with.
Also I didn’t see a method to dump all open id’s and their type. That would be useful.