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
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.