When called on a FAPL without ROS3 VFD block caching parameters
set on it, the H5Pget_fapl_ros3_block_caching() function previously
returned the VFD's default page buffer size value instead of its
default I/O block cache size value.
* Abort on infinite loop even when error output is disabled
* Remove abort() on infinite close loop
* Update CHANGELOG.md
* Reference the fixed issue in the CHANGELOG entry
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
The base type lookups in the object-tree helpers tested the
returned hid_t for truth rather than for a negative value. A failed
lookup returns H5I_INVALID_HID (-1), resolving true when checked, so any
failure wouldn't be caught until later.
When using the '-s' (h5ls) or '-r' (h5dump) option to display 1-byte integer datasets and attributes as ASCII characters, a closing double-quote character for data values was dropped in some cases.
Every CODEOWNERS "avalanche" (multiple owners of one area simultaneously
requested — on PR creation, on ready_for_review, or when a push first
touches an already-covered area) was resolved by re-running the
load-balancer from scratch, with no memory of who was already the
settled reviewer for that area. Since open-PR review load drifts over
time, this made the pick non-deterministic across repeated events and
caused three related symptoms:
- marking a draft ready for review could swap out reviewers who were
already assigned (manually or from an earlier pass) for different
people
- a routine follow-up push could re-avalanche an area and bump the
already-engaged reviewer for whoever currently has a lighter queue
- a manually re-requested reviewer survived the triggering event (the
existing forced-pick handling already covers that) but got silently
removed again on a later event, since two now-requested owners look
identical to an unpruned avalanche without that memory
Add a persisted per-area "sticky assignment" record (ASSIGNED_PREFIX,
alongside the existing exclusion and manually-added markers) and a
resolveAreaPicks() helper that prefers a valid sticky pick, then a lone
already-requested owner, before ever falling back to a fresh
load-balanced pick. Manual review_requested actions now write to this
record too, so a deliberate reviewer choice holds up across future
runs, not just the run it was made on.
Co-authored-by: H. Joe Lee <hyoklee@hdfgroup.org>
HDF5 discovers Java twice, through mechanisms with opposite search
precedence, and never reconciles them:
find_package(Java) in CMakeLists.txt sets Java_JAVA_EXECUTABLE,
Java_JAVAC_EXECUTABLE and Java_VERSION_STRING. FindJava searches
JAVA_HOME via HINTS, which outrank $PATH.
project(HDF5_JAVA C Java) in java/CMakeLists.txt sets
CMAKE_Java_COMPILER/RUNTIME/ARCHIVE. CMakeDetermineJavaCompiler searches
$ENV{JAVA_HOME}/bin only as a PATHS entry, the lowest priority slot,
below $PATH, and ignores the CMake variable JAVA_HOME entirely.
When JAVA_HOME and PATH refer to different JDKs the two diverge, so the
FFM/JNI version gate in java/CMakeLists.txt is evaluated against one JDK
while the code is compiled and tested with another. On macOS both resolve
to the /usr/bin stubs, which re-select a JDK from JAVA_HOME on every
invocation, so javac and java can differ inside a single build and every
Java test fails to load its class files with UnsupportedClassVersionError.
Propagate the probed toolchain before the Java language is enabled, filling
each variable independently. The guard in CMakeDetermineJavaCompiler.cmake
is if(NOT CMAKE_Java_COMPILER) and it closes only after the runtime and
archive lookups, so a caller passing just
-DJAVA_HOME=$JAVA_HOME -DCMAKE_Java_COMPILER=$JAVA_HOME/bin/javac
suppresses the other two lookups entirely and ends up with an empty
CMAKE_Java_RUNTIME and an empty TEST_JAVA in the generated CTest files.
Filling them one at a time keeps an explicit override working while still
completing the toolchain.
Verified two ways. Configuring with PATH -> JDK 11 and JAVA_HOME -> JDK 20
previously reported Java 20 and selected the JNI implementation while
CMAKE_Java_COMPILER, CMAKE_Java_RUNTIME and the generated TEST_JAVA all
pointed at JDK 11; they now all resolve to JDK 20. On macOS 26 arm64 with
JAVA_HOME -> JDK 25 the same build went from 95 failing Java tests to none.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
* Document the Metadata Cache Image block and header message
Adds docs/doxygen/dox/H5.format.4.0.dox coverage for:
- Level 1J: the Metadata Cache Image Block (subsec_fmt4_infra_mdci)
- IV.A.3.y: the Metadata Cache Image header message (0x0018)
- TOC/cross-reference entries and the superblock-extension list entry for both
Also clarifies the 'Size of Header Message #n Data' field description
for v1 and v2 object header messages to note it includes flags/reserved
(v1) or flags/creation-order (v2) fields, not just type and length.
* Address review feedback on MDCI message docs
- Clarify that the Metadata Cache Image message and its image block
are only removed/reclaimed on the next file open when the file is
opened for read/write access; read-only opens leave them unchanged.
- Fix a malformed table row (missing closing </td>) in the Status
field of the IV.A.3.y message table.
Address all zizmor 1.25.2 findings in the Maven/Java-themed workflows
with no behavioral change:
- template-injection: move attacker-controllable ${{ }} expressions
(matrix.*, runner.workspace, github.actor, github.base_ref,
steps.*.outputs.*, needs.*.outputs.*) out of run: script bodies into
step-level env: blocks referenced as shell/pwsh variables.
- artipacked: add persist-credentials: false to all actions/checkout
steps (none of these workflows push to git).
- excessive-permissions: add/tighten explicit permissions. Reduce
overly broad workflow-level packages:/pull-requests: grants to
contents: read, granting minimal packages: read/write only to the
specific jobs that need it.
- secrets-inherit (release.yml): remove secrets: inherit on the
test-maven-packages.yml call, which declares no workflow_call secrets.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Co-authored-by: Larry Knox <lrknox@hdfgroup.org>
* Harden workflow checkout credential hygiene + permissions
Address zizmor static-analysis findings:
- artipacked: add `persist-credentials: false` to actions/checkout
steps in codeql.yml (2), test-binary-installation.yml (2),
clang-format-check.yml, freebsd.yml, h5py.yml, openbsd.yml,
signed-plugins.yml, and update-progress.yml. None of these jobs
push to git, so dropping the persisted checkout credential is safe.
- excessive-permissions: restrict call-workflows.yml top-level
permissions to `contents: read`, and grant `packages: write` /
`pull-requests: write` only on the two jobs that call the
maven-staging reusable workflow (which declares those needs).
No behavioral change.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* Removed extra blank lines.
---------
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Co-authored-by: Larry Knox <lrknox@hdfgroup.org>
* Harden scheduled/downstream build workflows against zizmor findings
Fix all zizmor static-analysis findings in the scheduled/downstream build
workflows without changing behavior:
- template-injection: move ${{ }} expressions out of run: script bodies
into step-level env: blocks referenced as shell variables
- artipacked: add persist-credentials: false to actions/checkout steps
(none of these jobs push to git)
- excessive-permissions: add top-level 'permissions: contents: read' to
macos-26-matrix.yml (other files already restrict permissions)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* Address Copilot review comments on PR #6544
- Drop unnecessary command substitution in daily-schedule.yml's
FILE_NAME_BASE assignment
- Name the two env-block steps in daily-build.yml that previously ran
unnamed (easier to scan in logs)
- Quote $GITHUB_OUTPUT in the getinputs step
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* Remove extra blank lines.
---------
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Co-authored-by: Larry Knox <lrknox@hdfgroup.org>
Address GitHub Actions static-analysis (zizmor/CodeQL) findings in the
S3 publishing workflows:
- publish-release.yml: hoist every inputs/secrets/vars value used inside
run blocks into job-level env vars and reference plain shell variables
($USE_TAG, $FILE_NAME, $TARGET_DIR, $S3_BUCKET, $TARGET_PATH, $DRY_RUN),
eliminating 41 template-injection findings. Add persist-credentials:
false to the checkout (artipacked).
- publish-branch.yml: add persist-credentials: false to the checkout
(artipacked); its S3 sync already used env vars.
No behavioral change: the same values are used, only via the shell
environment instead of direct ${{ }} expansion into the script body.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
On SunOS the C and C++ flag files appended the single string
"-erroff=%none -DBSD_COMP" to HDF5_CMAKE_C/CXX_FLAGS. Because that is one
list element, target_compile_options() hands it to the compiler as one
argument, and -erroff is an Oracle Developer Studio option to begin with.
gcc silently ignores the result (it parses the leading -e as the linker
entry-symbol option), but clang errors out:
clang: error: unknown argument: '-erroff=%none -DBSD_COMP'
which breaks the build on the first object file. As a side effect,
-DBSD_COMP was never actually reaching the compiler as a define.
Emit -erroff=%none only for SunPro, and append -DBSD_COMP as its own list
element so it is passed as a separate argument on all Solaris compilers.
Fixes#6569
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
GitHub-hosted runners have no real InfiniBand, and the Open MPI bundled
with NVIDIA HPC-X intermittently has UCX select a non-functional verbs
interface (e.g. ud_verbs/mana_0), causing:
ucp_worker.c:1487 UCX ERROR uct_iface_open(ud_verbs/mana_0:1) failed
pml_ucx.c:319 Error: Failed to create UCP worker
MPI_INIT has failed because at least one MPI process is unreachable
which fails h5_api_test_parallel_* tests in the "Run Tests" step. This
only affects nvhpc.yml (HPC-X's bundled Open MPI ships UCX); main-par.yml
uses Ubuntu's openmpi-bin package, which doesn't use UCX and is unaffected.
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
* Add Fortran ABI compatibility check to abi-report workflow
Mirrors the existing C/HL/C++ abi-dumper + abi-compliance-checker
steps for libhdf5_fortran.so, plus a supplementary nm-based exported
symbol diff since gfortran's mangled names don't encode argument
lists and DWARF-based diffing has not been validated against
Fortran-specific constructs (array descriptors, derived types).
* Auto-detect ABI reference release instead of hardcoding it
file_ref was pinned to '2.0.0' in both daily-build.yml and release.yml
and had gone stale across two releases (2.1.0, 2.1.1) without being
bumped, silently comparing against a two-versions-old baseline. Have
abi-report.yml query the GitHub API for the latest published
HDFGroup/hdf5 release when file_ref isn't explicitly given, so callers
no longer need to remember to update a pinned tag after every release.
Verified the resolution command returns 2.1.1 against the live API.
Also documents the expected false-positive pattern in the new Fortran
ABI check: abi-dumper misreads gfortran's DWARF encoding of
assumed-shape array descriptors as fixed array bounds, producing bulk
Low-severity noise on the KIND/RANK-generated H5_gen.F90 procedures
that isn't a real interface change.
* Various improvement in documentation and a decoding function
- Improves documentation on the type size when creating/accessing a compound datatype with no predefined struct (GH issue #5371)
- Provides better description of the min_meta_perc and min_raw_perc arguments in the H5Pset_page_buffer_size() (GH issue #5711)
- Adds error checkings to an internal decoding function
* Corrected the checks, the base address equals the end-of-file is valid.
* Skip for multi-file and split drivers when validating addresses against stored_eof
* Committing clang-format changes
* Remove incorrect name
* Fix typos
* Modified description of type_size arguments
* Used a more robust condition when checking EOF
* Corrected incorrect conflict resolving
* Update src/H5Fsuper_cache.c
Co-authored-by: Neil Fortner <fortnern@gmail.com>
* Update src/H5Fsuper_cache.c
Co-authored-by: Neil Fortner <fortnern@gmail.com>
* Committing clang-format changes
* Modified per feedbacks.
* Fix comparison per feedbacks
* Omit unused parameter name in a catch block
---------
Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Neil Fortner <fortnern@gmail.com>
* fix: pre-size filter output buffer to avoid realloc fragmentation on Windows
When reading a filtered (compressed) chunk, filters like deflate initialize
their output buffer using *buf_size (the pipeline's buffer capacity hint).
With *buf_size set to chunk_disk_size (the compressed size), deflate grows
its output buffer via repeated realloc() doubling. On Windows this fragments
the heap and causes read times to increase steadily across iterations.
Set buf_alloc to MAX(chunk_disk_size, chunk_size) immediately before calling
H5Z_pipeline so filters pre-allocate their output at the full uncompressed
size and avoid realloc. The inbuf is still allocated at chunk_disk_size —
only the hint passed to the pipeline is enlarged — so there is no
double-large-allocation overhead and peak memory stays at
chunk_disk_size + chunk_size rather than 2 * chunk_size.
For incompressible chunks where chunk_disk_size > chunk_size the hint
remains at chunk_disk_size, satisfying H5Z_pipeline's post-filter size
validation.
Fixes#4481 and #4513.
* fix: return nbytes instead of *buf_size in nbit and scaleoffset no-op paths
Per the HDF5 filter API, nbytes is the count of valid data bytes in the
buffer, while *buf_size is the allocated buffer capacity. These two values
were historically always equal on the read path, so either worked in
practice. The pre-sizing change (which sets buf_alloc = chunk_size before
the filter pipeline) makes *buf_size > nbytes for compressed reads,
exposing the latent bug.
In H5Znbit.c: the no-compress pass-through (cd_values[1] == 1) was
returning *buf_size, causing the next filter (e.g. fletcher32) to treat
the full pre-sized buffer as valid data and compute a checksum over
uninitialised bytes.
In H5Zscaleoffset.c: the no-process path had the same pattern. No current
test exercises this path through a multi-filter pipeline where the size
mismatch would be observable, but the fix is correct by the same API
reasoning.
* experiment: deflate decompress reuses inbuf via H5resize_memory
Instead of allocating a fresh output buffer (H5MM_malloc), copy the
compressed input to a small temp buffer and resize *buf in-place via
H5resize_memory. On Windows, HeapReAlloc can often extend an existing
heap block without moving it, avoiding the cost of finding and committing
a fresh large allocation for every chunk read.
This is combined with the pre-sizing hint in H5Dchunk.c that sets
buf_alloc = chunk_size before the pipeline call, so the resize goes
directly to chunk_size in one step with no realloc loop.
* fix: pre-resize chunk buf in H5Dchunk.c so all filters see correct capacity
Replace the hint-only buf_alloc enlargement with an actual
H5D__chunk_mem_realloc() before calling H5Z_pipeline. Every filter now
sees *buf_size equal to the real buffer capacity, not just an advisory
hint. This fixes a bounds-check regression in H5Zscaleoffset where the
read path uses *buf_size as the end-of-buffer sentinel in
H5_IS_BUFFER_OVERFLOW and as the input-size argument to
H5Z__scaleoffset_decompress; an inflated hint caused false-negative
overflow checks and potential over-reads when scaleoffset is the on-disk
filter.
H5Zdeflate is simplified accordingly: the up-front H5resize_memory(*buf,
nalloc) is removed since the buffer is already at nalloc on entry. The
inbuf copy is retained (still needed to read compressed input while
writing uncompressed output into the same buffer), as is the
realloc-doubling loop for the uncommon case where output exceeds
chunk_size.
Also add test/chunk_deflate_perf.c, a standalone benchmark that times
per-chunk deflate reads over multiple passes to detect the steady read-time
increase caused by heap fragmentation on Windows (issues #4481 / #4513).
* Committing clang-format changes
* test: add file path argument to chunk_deflate_perf benchmark
Add optional 4th argument to specify the output HDF5 file path
(default: chunk_deflate_perf.h5 in CWD). Allows running develop
and fix builds against separate files so pass 1 is cold-cache for
both and the two runs don't share page-cache state.
* test: remove chunk_deflate_perf benchmark
Not suitable for the test suite; intended for manual Windows validation
only. Keep locally if needed.
* fix: pre-resize chunk buf in H5Dchunk.c so all filters see correct capacity
Allocate the chunk read buffer at MAX(chunk_disk_size, chunk_size) from
the start rather than allocating at chunk_disk_size and immediately
reallocating. The read only fills chunk_disk_size bytes regardless of
buffer size, so there is no cost to the larger initial allocation and the
separate realloc step is eliminated.
Every filter now receives *buf_size equal to the actual buffer capacity
with no additional allocation needed. On Windows a single HeapAlloc at
the correct size avoids the repeated realloc-doubling in the deflate
filter that fragments the heap and causes read times to increase over
successive iterations (issues #4481 / #4513). Also fixes the
scaleoffset bounds-check regression where *buf_size was used as an
end-of-buffer sentinel.
* revert: restore H5Dchunk.c and H5Zdeflate.c to pre-experiment state
Reverts the deflate in-place decompression experiment and the H5Dchunk.c
pre-sizing changes back to the state at 9ab5e191d7, keeping the nbit
and scaleoffset no-op path fixes.
* fix: allocate chunk buf at MAX(disk_size, chunk_size) before filter pipeline
The previous approach allocated the buffer at chunk_disk_size and then
bumped buf_alloc to chunk_size as a hint to the pipeline, causing *buf_size
to misrepresent the actual allocation. Any filter that writes up to
*buf_size bytes into *buf would overflow.
Allocate at MAX(chunk_disk_size, chunk_size) upfront so the buffer and
the hint given to filters are always consistent. For incompressible chunks
where chunk_disk_size >= chunk_size the allocation is unchanged.
* Use HGOTO_DONE(nbytes) for the scaleoffset no-op passthrough
Matches the macro convention used for the other early-return in this
function per bmribler's review comment on PR #6389.
---------
Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>
* Fix NULL pointer access when H5A_operator2_t is NULL
Passing NULL for the callback function pointer to H5Aiterate2 and
H5Aiterate_by_name was not detected, leading to a subsequent access
of an uninitialized pointer. Add a check for this "no operator
specified" case in both functions so they fail gracefully instead.
Fixes GHSA-r7g4-hv2f-5c66 - CVE-2025-9274
* Fix format
* Fix Java test to handle NULL callback to H5Aiterate2
* Fix JNI datatype ID leak in h5str_detect_vlen_str()
The JNI H5Dread/H5Dwrite/H5Aread/H5Awrite wrappers call h5str_detect_vlen()
on the memory type. For an H5T_ARRAY/H5T_VLEN of a fixed (non-vlen-string)
base type, h5str_detect_vlen_str() acquired the base type via H5Tget_super()
but only closed it when the recursive check returned 1 or a negative error.
When the recursive call returned 0 because no vlen string was found, the base type ID
was leaked.
This PR changes h5str_detect_vlen_str() to close the id unconditionally after the recursive check,
in the same style as the compound-member case in the same function.
A JNI regression test exists at TestH5D.testH5DArray_super_no_id_leak, which reads
an H5T_ARRAY-of-int dataset in a loop and asserts via H5Fget_obj_count() that
no datatype IDs leak.
* Assert non-negative H5Fget_obj_count in array datatype ID leak test
Guard the before/after open-datatype counts against a negative
(failed) H5Fget_obj_count return, which would otherwise let the
equality check pass spuriously. Keep the count scoped to
H5F_OBJ_ALL: the leaked IDs are transient datatypes not attached to
any file, so a per-file count would not see them.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* Modify CHANGELOG entry
* Modify CHANGELOG again
---------
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Co-authored-by: H. Joe Lee <hyoklee@hdfgroup.org>
Generate the Doxygen tag file inside the html output directory
(hdf5lib_docs/html/hdf5.tag) instead of at the build root. The S3
documentation publishing (daily "latest", release zip, and
publish-release) all derive from the docs-doxygen artifact, which is
uploaded from the build-tree html directory. Placing the tag file there
makes it flow to every destination, e.g.
https://support.hdfgroup.org/documentation/hdf5/latest/hdf5.tag
Since the tag file now lives inside html/, the existing DIRECTORY install
already installs it to ${HDF5_INSTALL_DOC_DIR}/html/hdf5.tag, so the
redundant standalone install(FILES ...) is removed (it would otherwise
reference a file that no longer exists at the build root).
* Add Next Release badge and Medium/Low priority progress badges
Adds a "Next Release" badge (in-development version from H5public.h)
and extends the existing Critical/High priority progress badges with
Medium (P2) and Low (P3) priority tracking, all fed from the same
GitHub Project #39 gist-based badge pipeline.
* Remove in-progress 2.0 entry from release schedule diagram
The Release Schedule chart is meant to show only past releases that
have reached end of life; the in-development series is now tracked
separately by the Release Progress badges. Regenerate the PNG from
the updated PlantUML source and clarify the README wording.
* Add Latest Release badge and milestone target date to Next Release
Fetches the most recent published release in the current major
version series from the GitHub Releases API (e.g. "2.1.1
(2026-03-23)") and exposes it as a new "Latest Release" badge.
Also looks up the target due date of the matching GitHub milestone
(e.g. "HDF5 2.2.0") and appends it to the existing Next Release
badge when one is set. Both lookups are independent of the
project-board query and degrade gracefully to "N/A" on failure.
The H5D__chunk_lock() call has a matching H5D__chunk_unlock() in normal conditions, but it is missing when an operation fails after H5D__chunk_lock() succeeds.
The previous `lib/cmake/hdf5-config.cmake` isn't in CMake's find_package
search path since CMake expects that to be a common path with each
package having it's own subdirectory. This changes it to
`lib/cmake/hdf5/hdf5-config.cmake` so the config is now found when the
install prefix is in `CMAKE_PREFIX_PATH`.
This also sets `HDF5_USE_GNU_DIRS=ON` by default for non-Windows builds.
Fixes#6137
Co-authored-by: Larry Knox <lrknox@hdfgroup.org>
- The layout of the shared message encoding was actually decribed at the beginning of the section IV.A.2.
For clarification, the section was split into two with one section purely for the shared message encoding
and another section for the catalog of message types.
- Cross-linked shareable messages to the shared message encoding section.
- Misc. cleanup
* Avoid converting fill value from memory to file type when reading vlen
data from a nonexistent chunk.
* Committing clang-format changes
* Add Changelog note
* Spelling
* Update changelog note
* Improve test description
* Hopefully make formatter happy
* Hyphenate read-only
---------
Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>
* Fix for issue #6430: add decription for H5Tencode/H5Tdecode to Appendix.
* Fix for issue #6392:
The fix addressed part 1 of the issue.
No change is needed for part 2 of the issue: verify that the info is already there in the Driver Info Message.
* Fix for issue #6360
* Fix for issue #6416 in section III.I. Disk Format: Level 1I - Shared Object Header Message Table.
---------
Co-authored-by: Matt L <124107509+mattjala@users.noreply.github.com>
* Add change-request and manually-added-CODEOWNER lines to review checklist
Reviewers who request changes now get their own line under each area
their inline comments touch, whether or not they're a CODEOWNER or a
requested reviewer. CODEOWNERS who are review-requested directly by a
human (rather than auto-picked) get a separate required-approval line,
and their approval is now required for that area's sign-off in addition
to the usual reviewer's.
* Prune reviewers whose area dropped out of scope
A CODEOWNER requested for an area the PR used to touch, before a later
push narrowed the diff, was never removed: touchedAreaOwners only
reflects areas touched right now, so none of the existing avalanche
pruning ever considered them. Reproduced live on PR #6528, where the
branch's diff shrank to just .github/ but gheber/fortnern/mattjala
(owners of unrelated areas) stayed as requested reviewers.
Manually-added CODEOWNERS are exempt, since a human's deliberate
request shouldn't be silently undone by a later push.
* review-checklist: fix avalanche exemption regressing genuine avalanches
#6524 exempted a review_requested login's whole area from avalanche
detection to stop a manual re-request from being undone. But a genuine
CODEOWNERS avalanche's own review_requested sub-events look identical
to that case, and one of them can survive the ready_for_review vs.
review_requested concurrency race (#6530: draft PR marked ready for
review left all 3 CODEOWNERS owners requested instead of pruning to
one, because the surviving run's action was one of the avalanche's own
review_requested events, exempting the whole area).
Replace the exemption with a forced pick: the directly-requested login
still always survives, but now by replacing the rest of that area's
avalanche instead of exempting the area from pruning — so a genuine
avalanche still collapses to one person. Also gate justRequestedLogin
on !isBotSender, matching updatedManuallyAdded's existing reasoning
just above it: the bot's own requestReviewers calls fire this same
event and aren't a human decision.
* bound SOHM list decode to list_max messages
* Add tsohm test for out-of-range SOHM list message count
Create a file with a shared-message list index, corrupt the on-disk
message count so it exceeds list_max (repairing the table checksum),
and confirm reopening rejects the file instead of overrunning the
list image buffer and message array.
---------
Co-authored-by: H. Joe Lee <hyoklee@hdfgroup.org>
Co-authored-by: Larry Knox <lrknox@hdfgroup.org>
* ROS3 VFD block cache feature
Implements a minimal I/O block cache for files without paged allocation
enabled to better optimize I/O and reduce requests to S3
I/O is cached in fixed-size blocks (16MiB blocks by default) and are kept
in a simple LRU cache that evicts the oldest used block when a new block
needs to be cached
Reading and caching of the initial bytes of a file has been delayed
from file open to the first read for a file instead
API functions have been added for setting/getting the I/O block caching
parameters to be used
* Address comments from review
* Rename 'page' -> 'block'
* Change default block cache size and separate from page buffer logic
* Update CHANGELOG
* Fix for issue #6430: add decription for H5Tencode/H5Tdecode to Appendix.
* Fix for issue #6392:
The fix addressed part 1 of the issue.
No change is needed for part 2 of the issue: verify that the info is already there in the Driver Info Message.
* Fix for issue #6360
---------
Co-authored-by: Matt L <124107509+mattjala@users.noreply.github.com>
jhendersonHDF
vchoi-hdfgroup
Matt LandClaude Opus 5
scivisionandscivision
Scot BreitenfeldandH. Joe Lee
Neil Fortner
Larry Knox
dependabot[bot]
bmribler
Chuck AtkinsandLarry Knox
