Format compatibility when re-opening files
This commit selects the best HDF5 format compatibility options when re-opening an existing netCDF-4 file for writing, such as appending, or adding new groups or variables.
The general objective is to make netCDF-4 files that can be read and written by all previous library versions. Optimal HDF5 v1.8 compatibility is selected whenever possible. Otherwise this falls back to the adequate v1.6 compatibility.
Format compatibility is a transient property of the HDF5 library, rather than baked in at file creation time. Therefore, compatibility options must be re-selected every time a netCDF-4 file is re-opened for writing.
This builds on the previous update for initial file creation, PR #1931, by @brtnfld, released in netcdf-c version 4.8.1.
In particular, this commit moves compatibility controls into a single central location, a new common function that is shared by both create and open functions.
For more details, see issue #951, also documentation at the top of libhdf5/hdf5set_format_compatibility.c.
This commit also makes several corrections and cleanups to previous comments about the use of related property lists.
2022-01-08 09:34:52 +08:00
|
|
|
# This is part of Unidata's netCDF package. Copyright 2018-2022,
|
|
|
|
|
# see the COPYRIGHT file for more information.
|
2018-05-09 02:20:55 +08:00
|
|
|
|
|
|
|
|
# Build the HDF5 dispatch layer.
|
|
|
|
|
|
|
|
|
|
# Ed Hartnett
|
|
|
|
|
|
|
|
|
|
# Get AM_CPPFLAGS.
|
|
|
|
|
include $(top_srcdir)/lib_flags.am
|
2019-03-10 11:35:57 +08:00
|
|
|
libnchdf5_la_CPPFLAGS = ${AM_CPPFLAGS}
|
2018-05-09 02:20:55 +08:00
|
|
|
|
|
|
|
|
# This is our output. The HDF5 convenience library.
|
|
|
|
|
noinst_LTLIBRARIES = libnchdf5.la
|
|
|
|
|
|
|
|
|
|
# The source files.
|
2018-07-17 22:29:47 +08:00
|
|
|
libnchdf5_la_SOURCES = nc4hdf.c nc4info.c hdf5file.c hdf5attr.c \
|
2018-07-19 21:23:03 +08:00
|
|
|
hdf5dim.c hdf5grp.c hdf5type.c hdf5internal.c hdf5create.c hdf5open.c \
|
2020-12-17 11:48:02 +08:00
|
|
|
hdf5var.c nc4mem.c nc4memcb.c hdf5dispatch.c hdf5filter.c \
|
Format compatibility when re-opening files
This commit selects the best HDF5 format compatibility options when re-opening an existing netCDF-4 file for writing, such as appending, or adding new groups or variables.
The general objective is to make netCDF-4 files that can be read and written by all previous library versions. Optimal HDF5 v1.8 compatibility is selected whenever possible. Otherwise this falls back to the adequate v1.6 compatibility.
Format compatibility is a transient property of the HDF5 library, rather than baked in at file creation time. Therefore, compatibility options must be re-selected every time a netCDF-4 file is re-opened for writing.
This builds on the previous update for initial file creation, PR #1931, by @brtnfld, released in netcdf-c version 4.8.1.
In particular, this commit moves compatibility controls into a single central location, a new common function that is shared by both create and open functions.
For more details, see issue #951, also documentation at the top of libhdf5/hdf5set_format_compatibility.c.
This commit also makes several corrections and cleanups to previous comments about the use of related property lists.
2022-01-08 09:34:52 +08:00
|
|
|
hdf5set_format_compatibility.c hdf5debug.c hdf5debug.h hdf5err.h
|
2018-05-09 02:20:55 +08:00
|
|
|
|
2019-02-25 07:54:13 +08:00
|
|
|
if ENABLE_BYTERANGE
|
Provide byte-range reading of remote datasets
re: issue https://github.com/Unidata/netcdf-c/issues/1251
Assume that you have the URL to a remote dataset
which is a normal netcdf-3 or netcdf-4 file.
This PR allows the netcdf-c to read that dataset's
contents as a netcdf file using HTTP byte ranges
if the remote server supports byte-range access.
Originally, this PR was set up to access Amazon S3 objects,
but it can also access other remote datasets such as those
provided by a Thredds server via the HTTPServer access protocol.
It may also work for other kinds of servers.
Note that this is not intended as a true production
capability because, as is known, this kind of access to
can be quite slow. In addition, the byte-range IO drivers
do not currently do any sort of optimization or caching.
An additional goal here is to gain some experience with
the Amazon S3 REST protocol.
This architecture and its use documented in
the file docs/byterange.dox.
There are currently two test cases:
1. nc_test/tst_s3raw.c - this does a simple open, check format, close cycle
for a remote netcdf-3 file and a remote netcdf-4 file.
2. nc_test/test_s3raw.sh - this uses ncdump to investigate some remote
datasets.
This PR also incorporates significantly changed model inference code
(see the superceded PR https://github.com/Unidata/netcdf-c/pull/1259).
1. It centralizes the code that infers the dispatcher.
2. It adds support for byte-range URLs
Other changes:
1. NC_HDF5_finalize was not being properly called by nc_finalize().
2. Fix minor bug in ncgen3.l
3. fix memory leak in nc4info.c
4. add code to walk the .daprc triples and to replace protocol=
fragment tag with a more general mode= tag.
Final Note:
Th inference code is still way too complicated. We need to move
to the validfile() model used by netcdf Java, where each
dispatcher is asked if it can process the file. This decentralizes
the inference code. This will be done after all the major new
dispatchers (PIO, Zarr, etc) have been implemented.
2019-01-02 09:27:36 +08:00
|
|
|
libnchdf5_la_SOURCES += H5FDhttp.c H5FDhttp.h
|
|
|
|
|
endif
|
|
|
|
|
|
2018-05-09 02:20:55 +08:00
|
|
|
# Package this for cmake build.
|
|
|
|
|
EXTRA_DIST = CMakeLists.txt
|
