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

Re: 20000313: Unreadable CDF-file

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: 20000313: Unreadable CDF-file
  • Date: Mon, 13 Mar 2000 09:18:27 -0700
>From: "DIETRICH,THOMAS (A-Germany,ex1)" <address@hidden>
>Subject: Unreadable CDF-file
>Organization: ?
>Keywords: 200003130913.CAA20662 netCDF CDL

Hi,

> Dear Support,
> would you be so kind and look into the attached CDF-file?
> I have the following problems:
> 1. The new nc_open simply says 'Invalid argument'
> 2. The older ncopen issues 'NC_xtypelen: Unknown type 13'

The file has evidently been corrupted somehow, because the 9th through
12th bytes of the file could not occur in a netCDF file, as explained
in "Appendix B: File Format Specification" of the C or Fortran NetCDF
User's Guide.  Specifically, if you use the Unix utility "od" to do a
hexadecimal dump of the file, the first few bytes appear as:

    $ od -x xx.nc | head
    0000000 4344 4601 0000 0000 0000 000d 0a00 0000
            ...

The first eight bytes look fine, starting with "43 44 46 01" which is
the netCDF "magic number" identifying the file as a netCDF file.  The
next four bytes "00 00 00 00" are interpreted as a 32-bit integer that
represents the number of records in the file, and the value 0 is
plausible.  The problem is with the next four bytes "00 00 00 0d"
which are supposed to either be all zero (indicating a file with no
dimensions) or the start of a dimension array, in which case they
should be "00 00 00 0a".  

The byte "0a" represents a "newline" character and the byte "0d"
represents a "carriage return" character as text characters in most
encodings.  So I suspect that what happened to your file is that it
was somehow run through a program that converts text files from one
form to another by replacing newlines with carriage returns followed
by newlines, for example.  Maybe you tried to FTP the file without
specifying the file was binary, which could cause such conversion.

It might be possible to recover the original netCDF file by reversing
the conversion, if you knew exactly what characters were converted,
but it's impossible to tell whether the occurrence of the "0d 0a" byte
sequence in the data is the result of conversion from "0a" or occurs
naturally as the bits in the numeric representation of a value.

> Thank you very much in advance
> Thomas Dietrich, Agilent Technologies
> 
> PS:
> Is there new information about the release of the final version 3.5 of
> netCDF software.
> (I am interested in the netcdf.dll for Windows NT)?

No, we're still waiting on the incorporation of the Fortran90
interface, which is scheduled to be completed this month.

> Does it fix function nc_inq_libvers() which erroneously returns "VERSION of
> Mar 17 1998 16:25:22 $"?
> (That's the only flaw I detected in the previous version; but that I would
> rather have fixed).

Yes, I think that has been fixed in the version 3.5 beta that's
currently available.

--Russ
_____________________________________________________________________

Russ Rew                                         UCAR Unidata Program
address@hidden                     http://www.unidata.ucar.edu