I’m emailing in case that anyone is still sprinting on the opposite side of the world.
I just realized that if you change to a new mapset using g.mapset and then quit (properly), the mapset you changed to with g.mapset appears as locked the next time you try to open it. This is in trunk, but may affect other versions.
Michael
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
On Sun, Feb 3, 2013 at 8:49 PM, Michael Barton <Michael.Barton@asu.edu> wrote:
I'm emailing in case that anyone is still sprinting on the opposite side of
the world.
I just realized that if you change to a new mapset using g.mapset and then
quit (properly), the mapset you changed to with g.mapset appears as locked
the next time you try to open it. This is in trunk, but may affect other
versions.
I am not sure what you mean. You use the g.mapset through menu (GRASS
working environment->Change mapset)?
Anna
Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
It doesn't matter how I use it.
If I ...
1. change from mapset A to mapset B using g.mapset
2. then quit GRASS (from within mapset B)
then when I restart GRASS, mapset B shows up as locked.
Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
On Feb 3, 2013, at 12:57 PM, Anna Kratochvílová <kratochanna@gmail.com>
wrote:
On Sun, Feb 3, 2013 at 8:49 PM, Michael Barton <Michael.Barton@asu.edu> wrote:
I'm emailing in case that anyone is still sprinting on the opposite side of
the world.
I just realized that if you change to a new mapset using g.mapset and then
quit (properly), the mapset you changed to with g.mapset appears as locked
the next time you try to open it. This is in trunk, but may affect other
versions.
I am not sure what you mean. You use the g.mapset through menu (GRASS
working environment->Change mapset)?
Anna
Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
grass-dev Info Page
Michael Barton wrote:
I just realized that if you change to a new mapset using g.mapset
and then quit (properly), the mapset you changed to with g.mapset
appears as locked the next time you try to open it. This is in
trunk, but may affect other versions.
It affects every version since the lock file was moved from $HOME to
the mapset directory (r12779) and g.mapset was added (r12822), between
5.4.0 and 6.0.0beta1.
The startup script creates the .gislock file in the initial mapset
directory. After the session shell terminates, it removes the lock
file which it created.
g.mapset creates a lock file in the new mapset directory and removes
the lock file from the old mapset directory.
For 7.0, I suggest updating the global "lockfile" variable in
lib/init/grass.py based upon the contents of the $GISRC file after the
session (shell, GUI, batch job) has finished.
--
Glynn Clements <glynn@gclements.plus.com>