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