Even Rouault

The main entry points where this should be done are in alg/gdalpansharpen.cpp and frmts/vrt/vrtpansharpened.cpp

> Did I miss something or is this a real problem ? yes, and not an easy one to fix. Basically the design of the global block cache isn't compatible...

> if first _tries_ to lock it (with a timeout 0) whatever the dataset it belongs to, so that if it fails, it is considered being in use and should...

Under which condition would you allow the flush of a cached block of another dataset than the current one ? See 2cef454ab06723a32379690b46581a40eb2e5af2 . The current strategy allow the eviction of...

> I would like to try my proposal just above of `std::unique_ptr GDALAbstractBandBlockCache::makeDatasetPurgeable(GDALDataset* d)` (or something like that) to locally let the user responsible of "there is no multi R/W...

> But if you really think that the pull request would be denied I wouldn't push the merge button myself. I have that feeling that block caching for write scenarios...

Sorry, but I would still be unenthusiastic to merge this... This might work, but good luck to document that (I have a hard time myself grasping this), and this will...

> the GDALDriver::Copy() does not copy metadata by default and there seem to be no option to do that automatically (I observed that with ENVI metadata describing the bands, for...

> I observed the non-copy of a "wavelength" metadataitem from ENVI metadata domain. as far as I can see, the ENVI driver only reports it on the read side, but...

I'm not sure how you could do what you want to do since that would involve mixing gdal_calc.py with the GDAL Python module. But you should already be able to...