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

[Radim Blazek]

On Sun, Sep 27, 2015 at 9:14 PM, Glynn Clements
<glynn at gclements.plus.com> wrote:
>
> 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.

The mapset I need to read from does not have to be current, but one
mapset must be current and G_gisinit() checks if user is owner of
current mapset. If the user is not owner of any mapset in the
location, what can be set as current mapset?

Radim

> 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>