[GRASS-dev] How to get data from a location where the user does not own any mapset?

[Glynn Clements]

Radim Blazek wrote:

> Perfect, that is what I need. Why GRASS_SKIP_MAPSET_OWNER_CHECK should
> not be set by programs for read only access?

If you only need to read a mapset, you shouldn't need to make it the
current mapset, nor should you try.

Making a mapset the current mapset means that any change to e.g. the
WIND or VAR files will modify the files in that mapset. Creating
temporary files will create them in that mapset. And so on.

Also, using g.mapset to make a mapset the current mapset will try to
write the .gislock file there, and will fail if that file exists and
the creator is still alive.

Needless to say, any operation which attempts to write to the mapset
will fail if the filesystem permissions don't allow the operation. An
environment variable won't change that.

And if a session is using a mapset as its current mapset, the contents
of the WIND and VAR files in that mapset can change at any time.

> > In short, it's a safety mechanism against people trying to share
> > directories by making them group-writeable without fully understanding
> > the implications.
> 
> I am only interested in read only access. The purpose is to be able to
> read and display data in QGIS. I believe that read only access to a
> location where the user does not own any mapset is a legal
> requirement, isn't it?

Many GRASS library functions assume the existence of a current mapset
which can be modified. The few modules which access a location other
than the one containing the current mapset use G_create_alt_env() and
G_switch_env() to temporarily select the "other" location while
performing specific (read-only) operations, then switch back
afterwards.

This is something of a kludge, and probably somewhat error-prone, but
it's all we have.

There have been some discussions on cleaning this up, but they never
really got anywhere.

For now, even accessing data in other mapsets in the same location
relies on a certain amount of luck. Changes to the cell/fcell files
are atomic; changes to other files aren't (at least, not by design;
changes to cellhd files end up being atomic purely by virtue of the
fact that cellhd files are typically smaller than the stdio buffer).

-- 
Glynn Clements <glynn at gclements.plus.com>