[GRASS-user] Error running g.mapset

[Markus Neteler]

On Sat, Oct 16, 2010 at 3:32 PM, Glynn Clements
<glynn at gclements.plus.com> wrote:
>
> Markus Neteler wrote:
>
>> > The underlying bug (init.bat doesn't set GIS_LOCK) is still present in
>> > 6.5-svn. It isn't applicable to 7.0, where init.sh/init.bat have been
>> > replaced by a Python script (which does set GIS_LOCK).
>>
>> I have found this GPL program to the the PID which is needed
>> to set GIS_LOCK:
>> http://www.scheibli.com/projects/getpids/
>>
>> Would that be of interest? Or is %RANDOM% together with something
>> else sufficient?
>
> AFAICT, GIS_LOCK needs to be set to an integer, but the actual value
> is irrelevant on Windows.

At this point, would adding this line suffice?

set GIS_LOCK=1

> g.mapset reads GIS_LOCK, passes it to $GISBASE/etc/lock, and checks
> that etc/lock returns a zero exit code.
>
> On Windows, etc/lock does nothing:
>
>        int main(int argc, char *argv[])
>        {
>        ...
>            if (argc != 3 || sscanf(argv[2], "%d", &lockpid) != 1)
>                G_fatal_error("usage: %s file pid", argv[0]);
>        ...
>        #ifdef __MINGW32__
>            G_warning("Concurrent mapset locking is not supported on Windows");
>            exit(0);
>        #else
>
> If GIS_LOCK isn't set, g.mapset will complain. If it doesn't parse
> with "%d", etc/lock will complain. Other than that, it shouldn't
> matter.

If there are no objections, I'll submit above.

Markus