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 <[email protected]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
