Opened 11 years ago

Last modified 8 years ago

#1658 new defect

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

Reported by: hamish Owned by: grass-dev@…
Priority: major Milestone: 6.5.0
Component: Default Version: svn-develbranch6
Keywords: g.rename, g.copy, overwrite Cc:
CPU: x86-64 Platform: Linux



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

G65> r.mapcalc one=1
G65> r.mapcalc two=2
G65> g.rename one,two
Rename raster <one> to <two>
G65> -r two

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

I just lost a map :-(


Change History (3)

in reply to:  description comment:1 by glynn, 11 years ago

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.
  1. 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().

comment:2 by hamish, 10 years ago

see also #767

Note: See TracTickets for help on using tickets.