[GRASS-dev] Locking is not supported on Windows

[Glynn Clements]

Paul Kelly wrote:

> > In the worst case, you could just create a lock file with a PID of
> > zero. Assuming that the find_process() check is removed from etc/lock
> > (kill() doesn't exist on Windows), the actual PID written to the file
> > won't matter.
> 
> But does that not mean that if there is a stale lockfile for whatever 
> reason, it can't be removed automatically and the user will never be able 
> to use that mapset? (I'm thinking that Windows users are especially 
> unlikely to go manually looking for the lockfile and deleting it.)

Correct.

One option would be to make etc/lock provide more detail if it fails
due to the lock being present, including the pathname of the lock
file, and a recommendation to manually delete it if you are certain
that no other GRASS sessions exist.

Another option is to change g.mapset to simply skip the locking step
on Windows. A user starts multiple sessions at their own risk.

Making locking actually work would require knowing how to check the
status of a process on Windows.

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