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 <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
