<div dir="ltr">doh! for me - yes you have. I will double check this. </div><div class="gmail_extra"><br><div class="gmail_quote">On 20 July 2016 at 14:58, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Le mercredi 20 juillet 2016 15:55:37, James Ramm a écrit :<br>
> I may very well be computing the file size wrong, my calculation is:<br>
><br>
> 1024 + nXSize * nYSize * 2<br>
<br>
</span>This might perhaps be not the issue in your case, but I warned you before<br>
about the potential int32 overflow. You should cast one of nXSize or nYSize to<br>
vsi_l_offset.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
><br>
> 1024 is the size of the header. Data on disk is written as an unsigned<br>
> short hence * 2.<br>
><br>
> I think this is correct when comparing with calculation to seek to a given<br>
> block offset in IReadBlock/IWriteBlock:<br>
><br>
> 1024 + nRecordSize * static_cast<vsi_l_offset>(nBlockYOff),<br>
><br>
> Where nRecordSize = nBlockXSize * 2<br>
><br>
> VSIFTruncateL would be preferred - I will keep looking at it to find what<br>
> Im doing wrong.<br>
><br>
> On 20 July 2016 at 14:35, Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br>
> > Le mercredi 20 juillet 2016 15:29:37, James Ramm a écrit :<br>
> > > The only 'fix' I can get working is to return a zero-filled array if<br>
> > > the call to VSIFReadL fails in IReadBlock.<br>
> > ><br>
> > > Given that ReadBlock checks whether the block index is valid, I think<br>
> > > it<br>
> ><br>
> > is<br>
> ><br>
> > > safe to assume that if IReadBlock is called, the data is expected to be<br>
> > > retrievable (i.e. VSIFReadL in IReadBlock would not fail due to a user<br>
> > > requesting a block that is out of bounds as that raise an error much<br>
> > > earlier), is it acceptable to do this?<br>
> > ><br>
> > > Any reason for VSIFReadL to fail for a valid block index where an error<br>
> > > would be preferable to a zero'd array?<br>
> ><br>
> > If the file is corrupted/truncated, it might be appropriate to return an<br>
> > error.<br>
> > Or if the operating system doesn't manage to read the block (disk<br>
> > corruption)<br>
> ><br>
> > I still don't get why VSIFTruncateL() wouldn't do the job. Are you sure<br>
> > you are computing correctly the file size when extending it ?<br>
> ><br>
> > > I also tried to see whether VSIGetRangeStatusL could be of any help.<br>
> > > Interestingly, for the newly created raster (without any data added),<br>
> > > it returns VSI_RANGE_STATUS_DATA for the very first block and<br>
> > > VSI_RANGE_STATUS_HOLE<br>
> > > for subsequent blocks.<br>
> ><br>
> > The granularity of the information is linked a disk sector (4 KB ? might<br>
> > depend on the filesystem) so it is not surprising that the first block<br>
> > returns<br>
> > DATA given there's an header.<br>
> ><br>
> > > On 14 July 2016 at 13:26, Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>><br>
> ><br>
> > wrote:<br>
> > > > Le jeudi 14 juillet 2016 13:07:42, jramm a écrit :<br>
> > > > > I added the following to the end of the Create method in<br>
> > > > ><br>
> > > > > frmts/northwood/grddataset.cpp:<br>
> > > > > vsi_l_offset nFileSize = 1024 + nXSize * nYSize * 2;<br>
> > > ><br>
> > > > --> beware of the potential int32 overflow in nXSize * nYSize<br>
> > > ><br>
> > > > > if (VSIFTruncateL(poDS->fp, nFileSize) != 0) {<br>
> > > > ><br>
> > > > > CPLError(CE_Failure, CPLE_FileIO,<br>
> > > > ><br>
> > > > > "Failed to allocate space for GRD<br>
> ><br>
> > file");<br>
> ><br>
> > > > > delete poDS;<br>
> > > > > return NULL;<br>
> > > > ><br>
> > > > > }<br>
> > > > > poDS->FlushCache(); // Write the header to disk.<br>
> > > > ><br>
> > > > > Unfortunately still receiving the error. I wonder if it would be<br>
> ><br>
> > better<br>
> ><br>
> > > > if<br>
> > > ><br>
> > > > > I explicitly write the zeros with VSIFWriteL?<br>
> > > ><br>
> > > > No, that's what VSIFTruncateL() is supposed to do, in a smarter way<br>
> > > > depending<br>
> > > > on filesystem capabilities.<br>
> > > ><br>
> > > > > --<br>
> ><br>
> > > > > View this message in context:<br>
> > <a href="http://osgeo-org.1560.x6.nabble.com/Error-in-GDALWarp-to-NWT-GRD-tp527613" rel="noreferrer" target="_blank">http://osgeo-org.1560.x6.nabble.com/Error-in-GDALWarp-to-NWT-GRD-tp527613</a><br>
> ><br>
> > > > 6<br>
> > > ><br>
> > > > > p5276347.html Sent from the GDAL - Dev mailing list archive at<br>
> > > ><br>
> > > > Nabble.com.<br>
> > > ><br>
> > > > > _______________________________________________<br>
> > > > > gdal-dev mailing list<br>
> > > > > <a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
> > > > > <a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
> > > ><br>
> > > > --<br>
> > > > Spatialys - Geospatial professional services<br>
> > > > <a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
> ><br>
> > --<br>
> > Spatialys - Geospatial professional services<br>
> > <a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
<br>
--<br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
</div></div></blockquote></div><br></div>