Opened 12 years ago

Closed 12 years ago

#1176 closed defect (fixed)

NetCDF Driver picks up zero length files

Reported by: kyngchaos@… Owned by: 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 (9)

comment:1 Changed 12 years ago 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...

comment:2 Changed 12 years ago 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.  


comment:3 Changed 12 years ago by warmerdam

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

comment:4 Changed 12 years ago by kyngchaos@…

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.

comment:6 Changed 12 years ago by kyngchaos

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

comment:7 Changed 12 years ago by warmerdam

Description: modified (diff)
Milestone: 1.4.1
Summary: new Idrisi support doesn't work with NetCDF enabledNetCDF Driver picks up zero length files

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;

comment:8 Changed 12 years ago 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;

comment:9 Changed 12 years ago by kyngchaos

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

comment:10 Changed 12 years ago by warmerdam

Resolution: fixed
Status: assignedclosed

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

Note: See TracTickets for help on using tickets.