Paulo van Breugel wrote: > Can't answer that, but I see that a related (?) ticket
#2434 isn't related to #2712. #2712 relates specifically to the null file compression changes. #2434 was opened a year before those changes were started. > https://trac.osgeo.org/grass/ticket/2434 was retargeted to 7.03? From the > description that issue seems to be very similar to the problem described > above? The problem described above: > > > WARNING: Unable to rename cell file > > > 'C:\GIS\GrassJvdS/latlong/YLD_NUT/.tmp/unknown/3988.0' to > > > 'C:\GIS\GrassJvdS/latlong/YLD_NUT/fcell/Shan3_CA_Renyi_0_0': File exists > > > WARNING: Unable to rename null file > > > 'C:\GIS\GrassJvdS/latlong_2005/YLD_NUT/.tmp/unknown/4100.1' to > > > 'C:\GIS\GrassJvdS/latlong_2005/YLD_NUT/cell_misc/Shan3_CA_Renyi_1_0/null': > > > File exists doesn't match the symptoms of either #2434 or #2712. In both of those cases, the rename() fails with EACCESS ("Permission denied"), which is symptomatic of the file being open. This case fails with EEXIST ("File exists"), which suggests that the destination file wasn't deleted first. On Unix, deleting the original isn't required (or even desired); rename() will atomically remove any existing file. Windows generates an error if the destination exists. So we (try to) remove it first (on all platforms). remove(path); if (rename(fcb->temp_name, path)) { G_warning(_("Unable to rename cell file '%s' to '%s': %s"), fcb->temp_name, path, strerror(errno)); stat = -1; } (close_new() in lib/raster/close.c). The warning suggests that the file exists and remove() failed to remove it. On Windows, that can happen if the file is open. And looking at r.biodiversity.py, I notice: grass.mapcalc("$outl = -1 * $outl", outl=out_renyi, overwrite=True, quiet=True) I.e. it's running r.mapcalc with the same map as both input and output. That isn't guaranteed to work. And in fact it doesn't, because the close_maps() function (which closes all of the input maps) is never actually called. So when it tries to close the output maps, which involves renaming the new cell/fcell/null files into place, the original cell/fcell/null files are still open for reading, meaning that the remove() will fail, as will the subsequent rename(). Having r.mapcalc close the input maps would avoid that, and should be done, but ultimately that's fixing the symptoms. r.biodiversity shouldn't be trying to modify out_renyi "in-place". It should create a new map then, if necessary, replace the original using g.remove and g.rename. One problem with in-place modification is that closing an output map writes a number of support files (history, range, quant, cats, histogram). But after closing the output maps, r.mapcalc will sometimes copy some of the metadata (cats, colors, history) from the input map. Currently, it only does this if the entire expression is just a map with optional modifiers, but it may get more "intelligent" in the future. Clearly, that's a problem if the input map has already been replaced. -- Glynn Clements <gl...@gclements.plus.com> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
