[gdal-dev] Error in GDALWarp to NWT_GRD

[Even Rouault]

Le mercredi 20 juillet 2016 15:29:37, James Ramm a écrit :
> The only 'fix' I can get working is to return a zero-filled array if the
> call to VSIFReadL fails in IReadBlock.
> 
> Given that ReadBlock checks whether the block index is valid, I think it is
> safe to assume that if IReadBlock is called, the data is expected to be
> retrievable (i.e. VSIFReadL in IReadBlock would not fail due to a user
> requesting a block that is out of bounds as that raise an error much
> earlier), is it acceptable to do this?
> 
> Any reason for VSIFReadL to fail for a valid block index where an error
> would be preferable to a zero'd array?

If the file is corrupted/truncated, it might be appropriate to return an error. 
Or if the operating system doesn't manage to read the block (disk corruption)

I still don't get why VSIFTruncateL() wouldn't do the job. Are you sure you 
are computing correctly the file size when extending it ?

> 
> I also tried to see whether VSIGetRangeStatusL could be of any help.
> Interestingly, for the newly created raster (without any data added), it
> returns VSI_RANGE_STATUS_DATA for the very first block and
> VSI_RANGE_STATUS_HOLE
> for subsequent blocks.

The granularity of the information is linked a disk sector (4 KB ? might 
depend on the filesystem) so it is not surprising that the first block returns 
DATA given there's an header. 

> 
> On 14 July 2016 at 13:26, Even Rouault <even.rouault at spatialys.com> wrote:
> > Le jeudi 14 juillet 2016 13:07:42, jramm a écrit :
> > > I added the following to the end of the Create method in
> > > 
> > > frmts/northwood/grddataset.cpp:
> > >     vsi_l_offset nFileSize = 1024 + nXSize * nYSize * 2;
> > 
> > --> beware of the potential int32 overflow in nXSize * nYSize
> > 
> > >     if (VSIFTruncateL(poDS->fp, nFileSize) != 0) {
> > >     
> > >               CPLError(CE_Failure, CPLE_FileIO,
> > >               
> > >                               "Failed to allocate space for GRD file");
> > >               
> > >               delete poDS;
> > >               return NULL;
> > >     
> > >     }
> > >     poDS->FlushCache(); // Write the header to disk.
> > > 
> > > Unfortunately still receiving the error. I wonder if it would be better
> > 
> > if
> > 
> > > I explicitly write the zeros with VSIFWriteL?
> > 
> > No, that's what VSIFTruncateL() is supposed to do, in a smarter way
> > depending
> > on filesystem capabilities.
> > 
> > > --
> > 
> > > View this message in context:
> > http://osgeo-org.1560.x6.nabble.com/Error-in-GDALWarp-to-NWT-GRD-tp527613
> > 6
> > 
> > > p5276347.html Sent from the GDAL - Dev mailing list archive at
> > 
> > Nabble.com.
> > 
> > > _______________________________________________
> > > gdal-dev mailing list
> > > gdal-dev at lists.osgeo.org
> > > http://lists.osgeo.org/mailman/listinfo/gdal-dev
> > 
> > --
> > Spatialys - Geospatial professional services
> > http://www.spatialys.com

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com