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.
>To: address@hidden >From: address@hidden (Martin Wheatley) >Organization: European Fusion Development programme >Keywords: 200210311100.g9VB0OX02923 netCDF nc_fdopen Hi Martin, > The JET project is part of the European Fusion Development programme > and we use NETcdf heavily for storing much of our processed data. > > Occassionally we have problems with our data server because of a > 'limitation' in the API to NETcdf. > > Could you consider a new "open" function? say nc_fdopen() that is > passed an FD that is already connected to the underlying NETcdf file > > The problem we have is that we generate the name of the file and pass > it to our data server which then opens it - unfortunately it may be > deleted from our HSM BEFORE the nc_open() is executed. With nc_fdopen() > then 'hole' would be closed since we have a mechanism in place to pass > open FDs and avoid the 'deletion hole' On the surface, this sounds doable, but I'll have to look into whether this is as easy to implement as I think. There may be some portability issues (netCDF must work on Win32 systems) and problems with a mismatch between what you can specify as the file made with open(2) and what nc_open() permits. If anyone there has already implemented a prototype of this, it would make it easier to figure out exactly what would work for you. Thanks for the suggestion. --Russ _____________________________________________________________________ Russ Rew UCAR Unidata Program address@hidden http://www.unidata.ucar.edu