[GRASS-dev] r.mapcalc suppressed error message

[Glynn Clements]

Markus Neteler wrote:

> my overnight job of data prosessing failed with:
> 
> GRASS 6.4.svn (patUTM32):~ > r.mapcalc
> "aqua_lst1km20031120.LST_Day_1km.filt2=if(aqua_lst1km20031120.LST_Day_1km.filt
> >= 0, aqua_lst1km20031120.LST_Day_1km.filt, null())"
>  100%
> ERROR: Unable to make mapset element
>        cell_misc/aqua_lst1km20031120.LST_Day_1km.filt2
>        (/home/neteler/grassdata/patUTM32/modisLST005/cell_misc/aqua_lst1km20031120.LST_Day_1km.filt2)
> 
> The true error is indeed
> GRASS 6.4.svn (patUTM32):~ > mkdir
> /home/neteler/grassdata/patUTM32/modisLST005/cell_misc/aqua_lst1km20030312.LST_Day_1km.filt2d
> mkdir: cannot create directory
> `/home/neteler/grassdata/patUTM32/modisLST005/cell_misc/aqua_lst1km20030312.LST_Day_1km.filt2d':
> Too many links
> 
> because of
> GRASS 6.4.svn (patUTM32):~ > l
> /home/neteler/grassdata/patUTM32/modisLST005/cell_misc/ | wc -l
> 31999
> 
> Could "Too many links" (and likewise) be made visible in r.mapcalc?

If anywhere, it would need to go into G__make_mapset_element() (or
possibly change G_mkdir() to signal the error itself).

By the time that the error is reported to the module, it's impossible
to tell whether the error originated within GRASS (so errno won't be
meaningful), or within the OS (where errno might be meaningful, if it
hasn't been modified by code cleaning up after the error).

Having GRASS library functions preserve errno so that individual
modules can perform the checks isn't feasible, IMHO. Developers will
just forget and end up trashing errno on the way up.

At present, G__make_mapset_element() doesn't examine the result of
G_mkdir() (which just returns the result of mkdir()). It just calls
G_mkdir(), then generates an error if the requested directory doesn't
subsequently exist. At this point, it's too late to distingush the
error, as access() can set errno itself.

If you want OS-level errors generally, we have two main options:

1. Provide "infallible" wrappers for all of the core POSIX library
functions, i.e. functions which call G_fatal_error() themselves if any
error occurs.

2. Provide e.g. G_fatal_system_error(), which behaves like
G_fatal_error() but appends the result of strerror() to the message.

The first option is easier, but you lose context. I.e. you get a
generic "error reading file" error rather than something which tells
you which file it was trying to read and why.

The second option means modifying code to use the new function and,
more significantly, restructuring it so that it actually checks all
library functions (rather than relying upon the failure to cause
another error later on), and ensuring that errno doesn't get trashed
between the system call and the point that you report the error.

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