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