Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Dennis, I use a simple hex dump for expediency. This misses files with a nonzero user block, but I think those are pretty rare in the climate community. For example, here is one of the test files in the latest Unidata distro. But I get the same result with a locally created file. mac56:~/netcdf/netcdf-c-4.4.1-rc2/nc_test4 55> od -tx1 -N9 ref_hdf5_compat2.nc 0000000 89 48 44 46 0d 0a 1a 0a 00 0000011 The superblock version number is the 9th (last) byte. This number matches what is reported by ncdump -hs in the new release. I have no reason to doubt the result from H5Pget_version. --Dave On Fri, Jun 3, 2016 at 4:59 PM, dmh@xxxxxxxx <dmh@xxxxxxxx> wrote: > HDF says the (superblock format) differences are: > Version 0 is the default format > Version 1 is the same as version 0 but with the “Indexed Storage > Internal Node K” field for storing non-default B-tree ‘K’ value. > Version 2 has some fields eliminated and compressed from superblock > format versions 0 and 1. It has added checksum support and > superblock extension to store additional superblock metadata. > Version 3 is the same as version 2 except that the field “File > Consistency Flags” is used for file locking. This format version > will enable support for the latest version. > It is possible that the H5Pget_version indicates not the true number, > but rather the lowest externally detectable version number or some such. > Do you have a pure hdf5 1.10 file to see that superblock number is > reported by ncdump -hs? > Or did you do a hex dump to see what is actually in the superblock? > =Dennis Heimbigner > Unidata > > > On 6/3/2016 4:11 PM, Dave Allured - NOAA Affiliate wrote: > >> Netcdf group, >> >> My team is starting to test netcdf-4.4.1-rc2 with the latest HDF5 >> library, currently 1.10.0-patch1. I see that netcdf-4 files are now >> being generated with superblock version 0 for the first time in the >> history of netcdf-4. Presumably this is a result of the recent format >> compatibility fix in 4.4.1. >> >> All the older netcdf-4 files that I sampled, back to the original >> netcdf-4.0 (2008), were created as superblock version 2. >> >> Are there any indications whether superblock 0 will be robust and >> interoperable, going into the future? >> >> --Dave > >
netcdfgroup
archives: