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

Re: 20021031: proposal to add an nc_fdopen() function to netCDF

>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