[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 20011130: netcdf: file locking?

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: Re: 20011130: netcdf: file locking?
  • Date: Fri, 30 Nov 2001 14:15:20 -0700
>To: address@hidden
>From: Choo Heng Kek <address@hidden>
>Subject: netcdf: file locking?
>Organization: Tropical Marine Science Institute, Singapore
>Keywords: 200111300900.fAU90TN03499 netCDF file locking

Hi,

> - Is it possible to NF_OPEN(...NF_WRITE...) a netCDF file and prevent
> other processes from NF_OPENing it?  I.e. is file locking implemented in
> netcdf 3.5?

No, netCDF is just like POSIX stdio in this respect.  It is designed
to permit one process having a file open for writing and several other
processes having the same file open for reading at the same time.
Any locking has to be done externally to the library.  As far as I
know, there is no portable way to prevent multiple writers of the same
file, which may be on a shared file server accessed across a network
by different programs running on Unix, Windows, and Mac platforms, for
example.

> - The userguide says that only one process may write to a given netcdf
> file.  I assumed that this meant that if there were 2 processes which
> issued NF_OPEN(...NF_WRITE...) on an existing netcdf file, one of them
> would return an error.  However, i tested this with a simple fortran
> program and neither process gave an error in opening the netcdf file. 
> Is this the correct behavior?

Yes.  It would be better if there were an easy way to prevent another
program from opening the same file at the same time for writing, but
given network latencies, file systems that support aliases (symbolic
links), and the constraint of not changing the file format, this may
not be practical.  I'm open to suggestions for how such a facility
could be implemented ...

--Russ

_____________________________________________________________________

Russ Rew                                         UCAR Unidata Program
address@hidden                     http://www.unidata.ucar.edu