[GRASS-dev] [bug #4426] (grass) Almost entire GRASS database deleted. Suspect grass startup.

[Michael Barton]

Cedric,

I grabbed all of your recent changes from the cvs last night so I could make
some modifications.

So I think I'm working with the same thing you are in terms of TclTk (though
my binary C files are from Lorenzo's 22 April build).

I just closed GRASS, then reopened it. It worked fine. No loss of data. It's
hard to see how the startup could do anything that would delete data. There
is nothing in the code that modifies anything. It just looks for stuff and
reads it.

The culprit must lie elsewhere.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


> From: Request Tracker <grass-bugs at intevation.de>
> Reply-To: Request Tracker <grass-bugs at intevation.de>
> Date: Mon,  8 May 2006 09:47:16 +0200 (CEST)
> To: <grass-dev at grass.itc.it>
> Subject: [GRASS-dev] [bug #4426] (grass) Almost entire GRASS database deleted.
> Suspect grass startup.
> 
> 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
> 
>