[GRASS-user] Problematic error with g.region

[Glynn Clements]

Jarek Jasiewicz wrote:

> The message is long, but problem potentialy dengerous.
> 
> The error mentioned ealier:
> 
> Erro setting region (Problem with g.region?): child procces aborted abnormaly 
> 
> 
> I solved it partially (in proccess described below the wind file has 
> been corrupted) and can be solved by simply copying wind file from 
> PERMANENT mapset and run g.region.

Using "g.region -d" should be sufficient.

> But something destroy the wind file 
> and that situation was reported not only by me.
> 
> Becouse problem seems dengerous (there is no access to data till wind 
> file is not reconstructed) So i decided do not repair my data if someone 
> think to look on this problem with detail.
> 
> Below is describing of the situation. If some addational informations or 
> tests are needed please let me know.

[snip]

> I added mapset and proformed several simple analysis. 
> in last of them I recive message:
> 
> map [maxic2] nie można zapisać wiersza 4811 (in english probably:
> map[maxic2] row 4811 cannot be written or I cannot write row 4811)

When reporting problems to the list, it helps if you can perform tests
after using:

	export LC_ALL=C

This will disable the use of translated messages.

In this case, the above is probably this:

    G_warning(_("map [%s] - unable to write row %d"), fcb->name, row);

from write_error() in lib/gis/put_row.c.

This error normally arises from exceeding some limit, either:

1. The 2GiB limit on a file, if GRASS was compiled without large file
support (LFS).

2. Exceeding your account's disk quota.

3. Running out of space on the partition (note that Linux normally
reserves 5% of the disk space for root).

If either 2 or 3 occurred, that could explain the corruption with the
WIND file: the program tries to modify it but there is no space
available to write the updated WIND file.

Unfortunately, it isn't straightforward to handle this situation
gracefully. You just have to ensure that you don't run out of disk
space.

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