On Sun, Sep 27, 2015 at 9:14 PM, Glynn Clements <[email protected]> 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 <[email protected]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
