[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 20021031: proposal to add an nc_fdopen() function to netCDF
- Subject: Re: 20021031: proposal to add an nc_fdopen() function to netCDF
- Date: Fri, 01 Nov 2002 16:21:11 -0700
>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