this bug's URL: http://intevation.de/rt/webrt?serial_num=4426
-------------------------------------------------------------------------
Subject: Almost entire GRASS database deleted. Suspect grass startup.
Platform: GNU/Linux/x86
grass obtained from: CVS
grass binary for platform: Compiled from Sources
GRASS Version: CVS development May 7th 2006
Virtually an entire mapset in a location was deleted somehow. These are all the things I can remember doing since the last time I saw it alive:
Short version: PLEASE AUDIT STARTUP SCRIPTS, g.mapsets.tcl !!!
Most of this is probably not interesting.
Files were still being listed when I worked on development on gis.m testing running v.digit started from a layer.
I made the commit: Digitizing a vector layer might actually work now. Todo: grab other layers that are selected and use them for the draw commands.
I made a bunch of changes to mouse scrolling in gis.m.
I tested gis.m and opening guis for a bunch of modules and moved the cursor around and used the mouse wheel and clicked on frames and things.
I made these commits:
* Mouse scroll the layer tree and options windows.
* Improvements to scrolling. Scrolling is much more specific (must have
heyboard or mouse focus). Binding scrolling is no longer a code leak.
I saved a scrolling change I hadn't saved and tested yet, made some more tests of gis.m just like above and made the commit: No more code or memmory leak. (Forgot to save part of edit before
testing and committing)
I started making edits to gronsole.tcl to fix scrolling.
I closed all of grass (I left)
I reopened grass by clicking on a launcher button that, in an xterm, runs:
bash -c "cd ~/grassdata; grass61"
I don't usually run grass this way. I think I normally open a terminal and run grass61.
The new startup screen came up; I was mildly surprised (I havn't seen it very many times yet). I clicked on the button in the lower left corner (Location and PERMANENT mapset were already selected).
I finished changes to gronsole.tcl (bindings on scrollings) and tested it. As I had suspected It didn't really work.
I got an email from Michael, "V.digit doesn't work with new maps??". I revisited the changes of my earlier commit "Digitizing a vector...". I observed that if I tried to make a new map like Michael did that my test for existing map failed with an error. I decided to just use the lack of an error as evidence of the existing map with g.findfile and changed the chunk of code to:
###############################################################################
# Determine if an element already exists
proc Gm::element_exists {elem name} {
set failure [catch {exec [list "|g.findfile" "element=$elem" "file=$name"] >& /dev/null}]
return [expr {! $failure}]
}
###############################################################################
I tested this, making a new map (newmaptest below (edited - not actual name; actual name reflected my frustration with committing a bug)). It worked. I then added a vector layer to gis.m and clicked on the button to list existing maps. The only one present was my new map. At this point I started looking around and found the following files:
. .. .bash_history .bashrc DEFAULT_WIND .gislock MYNAME .tmp vector WIND windows
./.tmp:
. .. Foxwaltz
./.tmp/Foxwaltz:
. .. 14033.0 14033.0.pgm 14033.0.ppm 14033.1
./vector:
. .. newmaptest
./vector/newmaptest:
. .. cidx coor dbln head hist topo
./windows:
. .. gism_temp_region
The existence of gism_temp_region and no other regions (I wasn't displaying anything) means that gis.m was run more recently than the failure, though that doesn't narrow it down much.
.bash_history reveals nothing. It doesn't really have the commands I've been running in the console.
The files DEFAULT_WIND and WIND both contain:
proj: 99
zone: 0
north: 1
south: 0
east: 1
west: 0
cols: 1
rows: 1
e-w resol: 1
n-s resol: 1
top: 1
bottom: 0
cols3: 1
rows3: 1
depths: 1
e-w resol3: 1
n-s resol3: 1
t-b resol: 1
Note: the proj corruption of my windows occured a while ago. At the time I associated it with the new ______ (I can't remember what). I have no idea how it happened. I'm not certain if that's the same "proj" and "zone" that used to pop up. I think it isn't because when I'd run g.region -p I the projection and
zone would show descriptive text too. The survival of this data (or reintroduction of it) could be a big clue.
Places that are likely to have caused this error:
The startup scripts
Things that were for sure run:
gis.m
v.digit
g.findfile
I also remember I accidentally ran g.mapsets.tcl from the menu while trying to open guis to scroll arround. I closed it by clicking the window close button. This is probably also worth looking into. (Little used, suspicious name)
-------------------------------------------- Managed by Request Tracker