Ticket #1176 (closed defect: fixed)

Opened 2 years ago

Last modified 1 year ago

NetCDF Driver picks up zero length files

Reported by: kyngchaos@kyngchaos.com Assigned to: warmerdam
Priority: high Milestone: 1.4.1
Component: GDAL_Raster Version: unspecified
Severity: normal Keywords:
Cc:

Description (Last modified by warmerdam)

When NetCDF support is built into GDAL, the Idrisi driver can't write RST files. Reading works. When using gdal_translate to write an Idrisi file (or in the gdalautotest), it gives an assertion error: 

gdal_translate -of RST rgbsmall.tif asdf.rst
Input file size is 50, 50
0posixio.c:396: failed assertion `extent != 0'
Abort trap

I thought it may have something to do with OS X threads (from the posicio.c reference), but disabling threads in gdal didn't help - same error.

Change History

01/02/07 16:36:14 changed by warmerdam 

I have tried to reproduce this on linux with FWTools 1.1.2 unsuccessfully.
The same translation works fine. 

I will test on MacOS X...

01/02/07 19:01:00 changed by warmerdam 

I was able to reproduce the problem on MacOS X, though I think it is only 
occuring there because the asserts() are compiled in. 

I think the problem is that ncopen() is called on a zero length file. 

I think the appropriate solution is to modify netcdfdataset::Open() to only
try and open files with the magic code "CDF\001" at the beginning.

01/02/07 19:09:15 changed by warmerdam 

This change will be a bit involved, so I am deferring it for now.

01/04/07 13:04:03 changed by kyngchaos@kyngchaos.com 

A workaround I found is to reorder the loading of formats in GDALAllRegister() so that netcdf is loaded AFTER idrisi.  This only works when both are built into GDAL, instead of my practice of having netcdf as a plugin.

03/31/07 16:28:51 changed by kyngchaos

Any chance of some fix making it into 1.4.1? At least the reordering in GDALAllRegister?

04/01/07 16:07:53 changed by warmerdam

  • summary changed from new Idrisi support doesn't work with NetCDF enabled to NetCDF Driver picks up zero length files.
  • description changed.
  • milestone set to 1.4.1.

I have added the following check in netCDFDataset::Open() which I think will do the trick. Currently the change is only in trunk, but I'll move it into the 1.4 branch once I have a chance to add a test suite entry for netcdf.

/* -------------------------------------------------------------------- */ /* Does this appear to be a netcdf file? */ /* -------------------------------------------------------------------- */

if( !EQUALN(poOpenInfo->pszFilename,"NETCDF:",7)

&& ( poOpenInfo->nHeaderBytes < 5

!EQUALN((const char *) (poOpenInfo->pabyHeader),"CDF\001",5)))

return NULL;

04/01/07 16:10:02 changed by warmerdam

Once more with format control: 

/* -------------------------------------------------------------------- */
/*      Does this appear to be a netcdf file?                           */
/* -------------------------------------------------------------------- */
    if( !EQUALN(poOpenInfo->pszFilename,"NETCDF:",7)
        && ( poOpenInfo->nHeaderBytes < 5 
             || !EQUALN((const char *) (poOpenInfo->pabyHeader),"CDF\001",5)))
        return NULL;

04/01/07 17:55:58 changed by kyngchaos

I put that right before "Try opening the dataset." in my 3/28 snapshot. That seems to work - no idrisi errors.

04/01/07 21:29:05 changed by warmerdam

  • status changed from assigned to closed.
  • resolution set to fixed.

change migrated into 1.4 branch as well, and a small netcdf test script has been added to autotest/gdrivers (trunk only).