Please help by suggesting what program could have done this short list of
symptoms:
All grass database files (vectors, rasters, regions, etc.) and their
directories completely removed.
Projection and other support files except for MYNAME removed. MYNAME still has
the correct name for the location, so the whole folder wasn't deleted.
WIND and DEFAULT_WIND either removed and rewritten with proj and zone lines or
all the defaults of 0 and 1 were written to the remaining files.
-------------------------------------------- Managed by Request Tracker
this happened to me about 10 years ago when working with GRASS4.1.
I was testing a completely rewritten version of r.flow and we have never figured out what caused it.
We could not track it to r.flow itself so it must have been something related to installing a new module
while working in an existing GRASS location and running that new module then erased the files.
But I have recompiled and installed new modules while running GRASS many times since then and
I haven't seen this happen anymore.
--
Helena Mitasova
Department of Marine, Earth and Atmospheric Sciences
North Carolina State University
1125 Jordan Hall
NCSU Box 8208
Raleigh, NC 27695-8208 http://skagit.meas.ncsu.edu/~helena/
email: hmitaso@unity.ncsu.edu
ph: 919-513-1327 (no voicemail)
fax 919 515-7802
Please help by suggesting what program could have done this short list
of symptoms:
All grass database files (vectors, rasters, regions, etc.) and their
directories completely removed.
Projection and other support files except for MYNAME removed. MYNAME
still has the correct name for the location, so the whole folder
wasn't deleted.
WIND and DEFAULT_WIND either removed and rewritten with proj and zone
lines or all the defaults of 0 and 1 were written to the remaining
files.
this suggests it happened during a session, g.region creates a new WIND
if it finds that it is missing.
were you in the PERMANENT mapset at the time?
stuff to check:
$GISBASE/etc/clean_temp
I always get lots of /tmp/grass6-$USER-$$ dirs left over after exiting
GRASS, suggesting they might not be getting removed correctly.
(maybe from repeated `grass61 -gui` <cancel> ?)
e2fsck?
It is interesting that directories were removed too(?), suggesting
"rm -rf" not "rm -f", or some sort of "find | rm -f":
A while back I made a mistake coding a script which didn't check that a
g.tempfile was successfully created. At the cleanup() stage it did
"rm -f ${TMP}*", but g.tempfile failed and TMP was unset, so it ran as
"rm -f *" and wiped off all the files (but not dirs) in a home dir.
luckily my victim had a recent backup
I don't think common unlink() will remove dirs.
Is there a map name with loc/mapset name the same as a map name?
corrupted stream of data sent to the shell? `find` files moved to
other parts of the file system?
It won't; unlink() removes files, rmdir() removes (empty) directories,
remove() removes either. There is no system call or library function
to delete a directory tree.
Is there a map name with loc/mapset name the same as a map name?
corrupted stream of data sent to the shell? `find` files moved to
other parts of the file system?
That's a useful point; "mv" and rename() will rename an entire
directory tree with no complaints.
The only "rm -rf" commands in etc/Init.sh shouldn't be able to remove
the wrong directory even if $tmp is unset or there were problems in
constructing its value.
The current clean_temp program only deletes files, not directories
(not even empty ones).