Even Rouault

> is it okay to keep this issue on hold for a few months longer? yes, no problem

@rcoup Aren't you the maintainer of gdal.ConfigurePythonLogging() ;-) ? If so, I'm happy to defer to you. But yeah its likely that "recent" changes have interfered with that. Making GDAL...

Perhaps: b67ab290f4811e4e6f38da66ff92d0561d937520 : "Python bindings: make sure that CPL_DEBUG=ON and gdal.UseExceptions() work fine during gdal.VectorTranslate() (and similar) (fixes #8552); accumulate CE_Failure messages during a GDAL call when gdal.UseExceptions() (fixes #8551)"

have you looked at https://gdal.org/development/rfc/rfc63_sparse_datasets_improvements.html ? and the Truncate() and GetRangeStatus() in VSIVirtualFileHandle ? They are implemented by the Win32 API. You might just have to implement IGetDataCoverageStatus() in RAWRasterBand

Probably that ENVIDataset::Close() in the bFillFile case should use Truncate() (which can actually enlarge file) rather than Seek(file_size) + Write(single zero). I don't remember the details if Seek()+Write() is considered...

What about having a special behaviour in IRasterIO(GF_Write, ....) that would detect that the provided buffer is fully zero/nodata value and call FSCTL_SET_ZERO_DATA. Perhaps controlled by an open option to...

> * or, in RasterIO, a special flag requesting that incoming data should be checked against 0 to allow FSCTL_SET_ZERO_DATA if relevant I don't think we need a special flag....

> I might have a strong argument against the overhead of auto-detecting zeros It would be worth benchmarking the actual cost of GDALBufferHasOnlyNoData()

I would be rather opposed to having a new method that would take explicitly file offsets. That would feel really awkward in the GDAL Dataset/RasterBand API which is totally agnostic...

> In the above code, is it necessary to initialize after malloc? hum.. if you pass a fully contiguous array (that is nPixelSpace, nLineSpace, nBandSpace describe a contiguous array), this...