[GRASS-dev] making g.remove less verbose

[Glynn Clements]

Jachym Cepicky wrote:

> since nobody complained, i commited the "verbosity" patch for g.remove
> to cvs.

Good.

> if there will be  no objections, i'll rewrite g.copy and g.rename on
> similar way

No objections from me.

> one question: in cmd/remove.c, lines 61 to 64 list of raster files is
> printed to stderr:
> 
>             G_warning(
>                _("[%s@%s] is a base map. Remove reclassed map%s first:"),
>                     name, mapset, (nrmaps > 1 ? "s" : ""));
> 
>             fprintf(stderr, " %s", *rmaps);
>             for(rmaps++; *rmaps; rmaps++)
>                 fprintf(stderr, ",%s", *rmaps);
>             fprintf(stderr, "\n");
> 
> which leds to
> 
> g.remove rast=pokus
> WARNING: [pokus at jachym] is a base map. Remove reclassed map first:
>  tmp at jachym
> 
> would it make sence, rewrite this fprintfs to G_warning too, so the
> result would be:
> 
> WARNING: [pokus at jachym] is a base map. Remove reclassed map first:
> WARNING: tmp at jachym

Merge the two inside the loop, so if you have multiple maps you would
get e.g.:

	WARNING: [pokus at jachym] is a base map. Remove reclassed map first: foo at jachym
	WARNING: [pokus at jachym] is a base map. Remove reclassed map first: bar at jachym

However, there are more important issues than the format of the
warning:

1. There should be some way to override this check in case you cannot
remove the reclass map(s) (e.g. due to filesystem permissions). As it
stands, if someone creates a reclass of one of your maps, you can no
longer remove that map with g.remove.

[You can get around this problem by ensuring that other users can't
write reclassed_to files in your mapset directories, but that requires
being wise before the fact.]

2. In the case where the map being removed is a reclass map, the code
doesn't check that the fopen(".../reclassed_to") succeeds; if the base
map is in a different mapset (e.g. PERMANENT), the fopen() may well
fail due to lack of write permission.

3. A related issue appears to apply to g.rename, i.e. it tries to
update any reclass maps with the new name of the base map, and
neglects to check whether the fopen() succeeds.

-- 
Glynn Clements <glynn at gclements.plus.com>