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? 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. On 14 July 2016 at 13:26, Even Rouault <[email protected]> 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-tp5276136 > > p5276347.html Sent from the GDAL - Dev mailing list archive at > Nabble.com. > > _______________________________________________ > > gdal-dev mailing list > > [email protected] > > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > -- > Spatialys - Geospatial professional services > http://www.spatialys.com >
_______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
