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