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

Re: netcdf problem

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: Re: netcdf problem
  • Date: Tue, 10 May 1994 09:40:42 -0600
> Organization: Harris ISD
> Keywords: 199405101423.AA07870

Hi Bob,

> I have a persistent bug whereby an netcdf file cannot be created
> successfully in a certain directory. When the file is "created", all the
> statuses come back OK. But when I try to access the file again to write
> more data to it, I am told it is "Not a netcdf file."

On what machine and operating system does this problem occur?  Are you using
version 2.3.2 of netCDF (the latest version from June 1993).  There have
been two patches since 2.3.2, but they would not be relevant to this problem.

When you use "ncdump" on the file, does it also produce the same error
message?

> This message appears when the correct magic number cannot be retrieved; I
> can't see what code writes this magic number to the created file, all I
> can find in the source is the routine xdr_cdf that checks it. (The number
> is not represented in our magic file.)

The magic number is just the first four bytes of the file, which should be
        C D F soh
This is written into the file when it is first created, in the function
xdr_cdf in netcdf/libsrc/cdf.c:

        /* magic number */
        if( !xdr_u_long(xdrs, &magic) )

> (This same code works fine in other directories. Yet the permissions on
> the directories are the same.)
> 
> Do you have any suggestions as to where to look for the problem?

If ncdump can't recognize the file as a netCDF file, then look at the first
four bytes in the file just after it is created and see if they are some
permutation of the correct bytes.  In this case, you are probably using an
XDR library that doesn't implement xdr_u_long() correctly.  I can't make any
sense out of the code working in one directory but not another.  There
should be no dependence on the current directory except whether it is
writable or not.  If you can create a small test program that demonstrates
the bug and that we can reproduce by running it here, we'll try to diagnose
the problem.

__________________________________________________________________________
                      
Russ Rew                                              UCAR Unidata Program
address@hidden                                        P.O. Box 3000
(303)497-8645                                 Boulder, Colorado 80307-3000