Dear all,
As I run Native Wingrass I believe that many times, when I need stop processing
by “brute force”, some unwanted “lost files”. As I am running relatively large raster maps
(~70,000 vs 65,000 pixels), I fill that the size of my “map set directory” are increasing
more than what I think is ok.
Is there a grass command that I can run and “repair” my mapset checking for
lost files, or unneeded files?
Best wishes
miltinho astronauta
brazil
Milton Cezar Ribeiro wrote:
As I run Native Wingrass I believe that many times, when I need stop
processing
by "brute force", some unwanted "lost files". As I am running relatively
large raster maps
(~70,000 vs 65,000 pixels), I fill that the size of my "map set directory"
are increasing
more than what I think is ok.Is there a grass command that I can run and "repair" my mapset checking for
lost files, or unneeded files?
$GISBASE/etc/clean_temp should clean up the temporary directory (which
is <database>/<location>/<mapset>/.tmp/<hostname>). Also, it should be
cleaned automatically upon exit, so exiting and restarting GRASS will
work.
We don't provide a "visible" command to do this because sometimes a
temporary file need to be kept around (mainly for XDRIVER, maybe also
for gis.m); the only time when it's definitely safe to clean the
temporary directory is on exit.
--
Glynn Clements <glynn@gclements.plus.com>
On Tue, 2008-11-18 at 18:56 +0000, Glynn Clements wrote:
Milton Cezar Ribeiro wrote:
> As I run Native Wingrass I believe that many times, when I need stop
> processing
> by "brute force", some unwanted "lost files". As I am running relatively
> large raster maps
> (~70,000 vs 65,000 pixels), I fill that the size of my "map set directory"
> are increasing
> more than what I think is ok.
>
> Is there a grass command that I can run and "repair" my mapset checking for
> lost files, or unneeded files?$GISBASE/etc/clean_temp should clean up the temporary directory (which
is <database>/<location>/<mapset>/.tmp/<hostname>). Also, it should be
cleaned automatically upon exit, so exiting and restarting GRASS will
work.We don't provide a "visible" command to do this because sometimes a
temporary file need to be kept around (mainly for XDRIVER, maybe also
for gis.m); the only time when it's definitely safe to clean the
temporary directory is on exit.
Hi!
What about the GIS_ERROR_LOG?
Right now this file is in my /home directory and occupies 187MB! Can we
safely remove it (since there are many not important messages there)?
Should we back it up?
Can the code that produces it modified on order to remove after some
time old entries (like old clean_temp)?
Kind regards, Nikos
Nikos Alexandris wrote:
What about the GIS_ERROR_LOG?
Right now this file is in my /home directory and occupies 187MB! Can we
safely remove it (since there are many not important messages there)?
Yes.
Should we back it up?
That's up to you, but I wouldn't.
Can the code that produces it modified on order to remove after some
time old entries (like old clean_temp)?
GRASS only writes to that file if it already exists; nothing in GRASS
should ever create it.
If it doesn't exist, error message just go to stderr (i.e. the
terminal, unless it has been redirected).
--
Glynn Clements <glynn@gclements.plus.com>
On Tue, 2008-11-18 at 21:46 +0000, Glynn Clements wrote:
Nikos Alexandris wrote:
> What about the GIS_ERROR_LOG?
>
> Right now this file is in my /home directory and occupies 187MB! Can we
> safely remove it (since there are many not important messages there)?Yes.
That's good 
> Should we back it up?
That's up to you, but I wouldn't.
> Can the code that produces it modified on order to remove after some
> time old entries (like old clean_temp)?GRASS only writes to that file if it already exists; nothing in GRASS
should ever create it.
What created it in my computer? I certainly did not created this on
purpose. Perhaps I did something which has this "side-effect"... but
nothing that I am aware of.
If it doesn't exist, error message just go to stderr (i.e. the
terminal, unless it has been redirected).
Nikos
Nikos Alexandris wrote:
> > Can the code that produces it modified on order to remove after some
> > time old entries (like old clean_temp)?
>
> GRASS only writes to that file if it already exists; nothing in GRASS
> should ever create it.What created it in my computer?
You tell me 
I certainly did not created this on
purpose. Perhaps I did something which has this "side-effect"... but
nothing that I am aware of.
In the ~8 years that I've been working on GRASS, I've never had that
file materialise on its own.
If you haven't deleted it yet, look at the beginning of the file; it
might jog a memory regarding what you were doing when it was created.
--
Glynn Clements <glynn@gclements.plus.com>
On Wed, 2008-11-19 at 02:35 +0000, Glynn Clements wrote:
Nikos Alexandris wrote:
> > > Can the code that produces it modified on order to remove after some
> > > time old entries (like old clean_temp)?
> >
> > GRASS only writes to that file if it already exists; nothing in GRASS
> > should ever create it.
>
> What created it in my computer?You tell me
Hahahah 
That's funny. Glynn, sorry... Really, I have no idea.
> I certainly did not created this on
> purpose. Perhaps I did something which has this "side-effect"... but
> nothing that I am aware of.In the ~8 years that I've been working on GRASS, I've never had that
file materialise on its own.If you haven't deleted it yet, look at the beginning of the file; it
might jog a memory regarding what you were doing when it was created.
No I did not erase it. I was curious... waiting for your *lights*. So
here it is:
# the *amazing ERROR logger* file is located in /home/nik
ls -lah GIS*
-rw-r--r-- 1 nik nik 187M 2008-11-18 12:26 GIS_ERROR_LOG
# starts with
head -24 GIS_ERROR_LOG
---------------------------------
program: clean_temp
user: nik
cwd: /home/nik
date: Tue Feb 5 08:38:26 2008
error: LOCATION << /grass_db/9882.tmp >> not available
-------------------------------------
-------------------------------------
program: ?
user: nik
cwd: /home/nik
date: Tue Feb 5 08:38:27 2008
error: /usr/lib/grass/etc/lock:
-------------------------------------
-------------------------------------
program: clean_temp
user: nik
cwd: /home/nik
date: Tue Feb 5 08:47:15 2008
error: LOCATION_NAME not set
-------------------------------------
# ends with some error messages from today like "No such monitor as <x>
# total lines!!!
cat GIS_ERROR_LOG | wc -l
5775484
# errors logged
cat GIS_ERROR_LOG | grep error | wc -l
8868
WoW... I can see every mistake/error that I did/occured while working
with GRASS since February the 5th of 2008
I don't want to erase it now... !! Hahahha... I want to have a closer
look :-p
This info could be in some way useful... ?? No? In fact I was about to
ask these days how can someone estimate the total time invested on a
project. Sure, this GIS_ERROR_LOG isn't the answer for that but some
similar could work on the backgroun upon user demand (?).
Cheers, Nikos
Nikos Alexandris wrote:
This info could be in some way useful... ?? No? In fact I was about to
ask these days how can someone estimate the total time invested on a
project. Sure, this GIS_ERROR_LOG isn't the answer for that but some
similar could work on the backgroun upon user demand (?).
bash records commands in the .bash_history file (for GRASS, this is
kept in the mapset directory). You can set HISTSIZE and HISTFILESIZE
to control how many commands it remembers.
--
Glynn Clements <glynn@gclements.plus.com>