R: [GRASS-dev] Locking is not supported on Windows

[Glynn Clements]

marco.pasetti at alice.it wrote:

> Hi,
>  
> thanks to all for the exhaustive replies.
>  
> >Are you sure? AFAICT, etc/lock should always succeed on Windows, i.e.
> >it won't stop you from having two sessions with the same current
> >mapset. You will get a warning, but the mapset should still be
> >changed.
>  
> sorry but not. I tried to find out why here
> http://trac.osgeo.org/grass/browser/grass/branches/develbranch_6/general/g.mapset/main.c
> but I still don't know many things in GRASS code to
> understand it well (and my C is very very rusty). I just found that at
> lines 155-156 a conditional calls G_fatal_error if the GIS_LOCK env var
> is not set (var retrieved at line 154).

Right. But in that case, it should fail with "Unable to read GIS_LOCK
enviroment variable". If it gets as far as etc/lock generating the
"Locking is not supported on Windows!" warning, that implies that
GIS_LOCK is set.

If GIS_LOCK isn't being set, you can just modify the init.bat script
to set it, e.g.:

	set GIS_LOCK=0

The value doesn't matter; it's only used to detect stale lock files,
and that part won't work on Windows any time soon.

> >If g.mapset doesn't work, you can always change the GISDBASE,
> >LOCATION_NAME and MAPSET variables directly with g.gisenv.
>  
> Yes, it doesn't produce errors, but it doesn't change the
> location/mapset!

g.gisenv will definitely work, at least for the command line. It looks
as if the wxPython GUI may maintain its own separate GISRC file; if
that's the case, neither g.mapset nor g.gisenv will affect it.

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