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, Rob Ross wrote: > Also, I stand corrected -- you are right that there don't appear to be > any calls to fsync() in netCDF (at least version 3.6.3 that I just > looked through). That, obviously, surprises me. It surprised me too, when I looked for the fsync() call in nc_sync(). The documented way to share access among processes to the same file is to call nf90_open with the NF90_SHARE flag: The NF90_SHARE flag is appropriate when one process may be writing the dataset and one or more other processes reading the dataset concurrently ... but with no fsync() call and no call to fcntl using O_SYNC, it looks like the documentation for the nc_sync() function and corresponding nf90_sync function is inconsistent with the implementation. Just out of curiosity, did you try using the NF90_SHARE flag on the create/open calls in the writing and reading processes to see if that makes any difference? The lack of an fsync() call in the netCDF-3 library is not a recent change. I checked older versions and it hasn't been there at least back to version 3.4 released in 1998. I will have to do some research to see whether avoiding fsync() was entirely a portability issue for use on non-Unix systems, or whether there was some other intention. But for now, I agree that it looks like calling nc_sync() ought to also call fsync() on the underlying file descriptor. If nc_sync() did that, there would be no need for a new nc_fsync() function. Thanks for bringing this issue to our attention. --Russ
netcdfgroup archives: