g.rename, g.copy do not ask for --overwrite, they just do it

[hamish]

Hi,

discovered in devbr6, but may happen in other branches too:

G65> r.mapcalc one=1
 100%
G65> r.mapcalc two=2
 100%
G65> g.rename one,two
Rename raster <one> to <two>
G65> r.info -r two
min=1
max=1
G65> echo $GRASS_OVERWRITE

G65> r.mapcalc three=3
 100%
G65> g.copy three,two
Copy raster <three@user1> to current mapset as <two>
G65> r.info -r two
min=3
max=3

I just lost a map :-(

Hamish

[glynn]

Replying to hamish:

discovered in devbr6, but may happen in other branches too:

In 7.0 SVN:

$ g.rename one,two
<two> already exists in mapset <glynn>

In 6.5, g.copy etc have the same logic (checking module->overwrite), but it doesn't work correctly with 6.5's G_parser(), which needs

	module_info.overwrite = 0;

at the beginning of the check_overwrite() function.

The overwrite field of the GModule structure serves two purposes:

1. If it is set by the module prior to calling G_parser(), the --o flag will be listed in the --help (etc) output even if no options have "new" in the gisprompt field. This is required for modules such as g.copy and r.mapcalc which have output maps specified by means other than "output=" options.

2. It is set by G_parser() if the --o or --overwrite options were given, the GRASS variable OVERWRITE is set to a non-zero value, or the environment variable GRASS_OVERWRITE is set to a non-zero value.

In 7.0, G_parser() explicitly sets it to zero if --help or similar aren't being used. 6.x doesn't do this, so setting it before calling G_parser() to indicate that --o is accepted will result in it always being set upon return from G_parser().

[hamish]

see also #767

[wenzeslaus]

Please, have a look at a test for g.rename in version 7 (trunk) and add cases which you think are missing:

• source:trunk/general/g.rename/testsuite
• ​http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2015-02-15-08-00/report_for_nc_spm_08_grass7_nc/general/g.rename/test_overwrite/index.html