Hi Jim, I'm curious how the original file you provided was created and perhaps modified. It has a peculiar alignment characteristic that I haven't seen before, and if there are more netCDF files being created the same way, we may nned to adapt. Could you tell me the history of the file, what file system it was written on, and whether the netCDF library with which it was written was modified in any way? The file has this characteristic, which would indicate a non-Posix file system: it is using 512-byte alignment of data values rather than the 4-byte alignment assumed by netCDF. So, for example, the data block for fixed-size variables begins with 9 scalar integers that should take 4 bytes each. The offsets computed for these values from the beginning of the fixed-size data block are 0, 4, 8, 12, 16, 20, 24, 28, 32, so there is no padding or wasted space. The offsets from the beginning of the fixed-size data block that are actually stored in the header for these variables are 0, 512, 1024, ... , 4096. If the file system used to write the data originally could not write data on 4-byte boundaries, I think that violates the assumption of netCDF and POSIX I/O. Nevertheless, if the nc_endef() call pays attention to the file offsets for each variable that are stored in the header (as the netCDF library does when reading the file), rather than computing them from assuming 4-byte alignment, perhaps this file can be modified correctly. The function where we might be able to adapt to this is nc3internal.c:NC_begins(), which is called from nc3internal.c:NC_enddef(). In any case it's a netCDF bug to write something that can't be later read correctly, so if our unmodified library wrote that file and we can't adapt to it, then it was a bug to not emit an error message for trying to create a file on the original non-POSIX file system. Also, the data seems to all be there in the "corrupted" file, which can be fixed by just restoring the variable offsets in the file header to the peculiar values in the original ... --Russ Russ Rew UCAR Unidata Program address@hidden http://www.unidata.ucar.edu Ticket Details =================== Ticket ID: KLB-596506 Department: Support netCDF Priority: Normal Status: Closed
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.