Issue252 - dealing with user blocks in front of HDF5 superblocks - #258
Issue252 - dealing with user blocks in front of HDF5 superblocks#258bnlawrence wants to merge 8 commits into
Conversation
…but preserving nicer behaviour as a keyword option
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #258 +/- ##
==========================================
+ Coverage 78.48% 78.59% +0.11%
==========================================
Files 15 15
Lines 3416 3485 +69
Branches 546 555 +9
==========================================
+ Hits 2681 2739 +58
- Misses 593 602 +9
- Partials 142 144 +2 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
@davidhassell When you do the review, the only consideration I have is whether or not we should do an if in the high-level file initialisation and only add the |
|
Actually, I think I should just do this. Fix incoming. |
davidhassell
left a comment
There was a problem hiding this comment.
Hi Bryan,
Nice job. All makes sense, and I can see that it optimised in the "not constantly adding zero when there's no user block" sense.
The test is simple but effective.
decode_vlen
This also looks OK, in terms of the tests look sensible and pass, and the core logic makes sense.
Should we also not the in the PR that this fixes #228?
Description
#252 exposed a problem with our superblock handling. The HDF5 spec allows a user block in front of the HDF5 itself, and HDF5 implementations should look for the superblock at 0, and then at powers of 2 greater than 512 bytes. This means that if we don't find a superblock at offset zero, we have to go looking for where it might be before rejecting the file as not being an HDF5 file.
Closes #252
Checklist