[GRASS5] Re: Multiuser grass projects

[Glynn Clements]

Martin Pokorny wrote:

> >> What are other people doing with projects/jobs that require
> >> multiple users to access grass files? It seems that data
> >> permissions are enforced at the owner level which stops a group
> >> from sharing project files.
> >> 
> >> Is there a rational for this level of restriction?
> > 
> > My guess is that it's an indirect form of locking. Each user can
> > only have one session active at a time, each mapset directory can
> > only be modified by its owner, therefore you can't have multiple
> > sessions modifying the same mapset concurrently.
> > 
> > Two issues mean that this mechanism isn't particularly reliable:
> > 
> > 1. The one-session-at-a-time rule can be circumvented just by
> > changing the value of HOME (the lock file is $HOME/.gislock5).
> > 
> > 2. Nothing prevents a user from running programs in the background.
> > 
> > However, it does prevent users from accidentally shooting each other
> > in the foot.
> > 
> >> Is there a work-around I'm missing?
> 
> I recently investigated this topic with GRASS by implementing POSIX
> file locking. This was relatively easy to do because I was able to
> insert most of the requisite code into the GRASS GIS library "open
> file" functions, and did not have to worry about closing files because
> the POSIX file locks are automatically freed when a file is closed.
> Depending on the version of NFS you use, such a solution might be
> usable on NFS-mounted directories (or not). I have not experimented
> with my modifications enough to ensure their reliability and
> robustness, however. With such a solution, proper group permissions
> will allow file sharing in GRASS mapsets.

Locking individual files in G_open_cell() etc won't work as a general
solution; there just isn't enough context.

A module may read and write several files, and to be safe, everything
which it reads or writes must be locked against all other accesses
from the point that the first file is opened to the point that the
last file is closed.

Actually, even locking the entire mapset doesn't quite achieve this. 
Most GRASS modules can read maps from mapsets other than the current
one. If another session happends to be modifying that mapset, the
result is undefined.

Modifications to the actual raster data aren't a problem;
G_open_cell_new() etc write to a temporary file which is renamed upon
closure. Unix filesystem semantics ensure that, if another session was
reading the file, it's contents will still be available to the reader
even after it has been "deleted" (at least on a real Unix; this isn't
true for Cygwin, but I doubt that a Cygwin installation will be
multi-user).

However, if a module reads multiple components (cellhd, data, colour
table, history, ...) from a map in another mapset, and another session
is modifying that map, the various components may not correlate.

Just because nobody has reported having been bitten by this, it
doesn't mean that it can't happen.

I don't see any prospect of fixing this in 5.0.x; IIRC, the intention
is to change the directory layout for 5.1, from MAPSET/COMPONENT/MAP
to MAPSET/MAP/COMPONENT (or is it MAPSET/TYPE/MAP/COMPONENT, where
TYPE is cell/vector etc?). That would make it much easier to lock
entire maps; e.g. ensure that every map contains a component such that
locking that component locks the entire map.

-- 
Glynn Clements <glynn.clements at virgin.net>