NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Hi Thomas,It *looks* like NC_sync (an internal function) could check a flag to see if it should sync and then do so after writing header or numrec data, or if variables were updated.
Rob On Oct 28, 2009, at 11:29 AM, Thomas Orgis wrote:
Am Wed, 28 Oct 2009 16:49:54 +0100 schrieb Thomas Orgis <Thomas.Orgis@xxxxxx>:Main point of this discussion is the nc_fsync(), or any better named function, to time actual data write action, and I would be happy if it could make its way into a future NetCDF release.After reflecting with Rob, I think an extra flag to nc_open to modify the nc_sync() behaviour to include fsync() would be better than introducing another function for this. I am not totally sure now if nc_sync() should call fsync() only when it actually had dirty data to write or always... Not sure how it is organized inside NetCDF code (if nc_sync() is used a lot internally, for example)... we need to make sure that any write since the last fsync() triggers a call to fsync() on the next call to nc_sync().Alrighty then, Thomas.
netcdfgroup archives: