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

[netCDF #CIK-876600]: Yet another NC_DISKLESS question

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: [netCDF #CIK-876600]: Yet another NC_DISKLESS question
  • Date: Mon, 02 Jul 2012 10:28:59 -0600
charlie-
The reason the second open fails is that
nc_create with NC_DISKLESS (with NC_WRITE)
creates the file
to ensure that it can be created and written,
but it does not actually write anything until
nc_close is called. So, the nc_open opens
an empty file, which is of course not a legal
netcdf file hence NC_ENOTNC error.

You note:
"...I thought somehow the netCDF
library would keep track of diskless files created in memory and treat
them the same as if they were on disk, i.e., would succeed at opening
and returning nc_ids to them..."

In fact netcdf never checks to see if two ncids actually
refer to the same physical file. In the presence of symbolic
and hard links, this is actually a non-trivial check.

More to the point, why are you doing this? Even with regular files
and in the presence of internal buffering in memory, you can never be sure
that a file that is being created is in a consistent state on disk.
You might under certain circumstances see the same behavior with a regular
(non-diskless) file if the meta-data is still in memory and has
not been pushed to disk by the netcdf library.

If you give me your use case, maybe we can come up with a work-around.


=Dennis Heimbigner
  Unidata


Ticket Details
===================
Ticket ID: CIK-876600
Department: Support netCDF
Priority: Normal
Status: Closed