[GRASS-dev] Re: [GRASS GIS] #226: WinGRASS fails to create .gislock opening a mapset

[GRASS GIS]

#226: WinGRASS fails to create .gislock opening a mapset
----------------------------+-----------------------------------------------
 Reporter:  msieczka        |       Owner:  grass-dev@…              
     Type:  defect          |      Status:  new                      
 Priority:  major           |   Milestone:  6.4.2                    
Component:  Default         |     Version:  svn-develbranch6         
 Keywords:  wingrass, qgis  |    Platform:  MSWindows XP             
      Cpu:  All             |  
----------------------------+-----------------------------------------------

Comment(by glynn):

 Replying to [comment:11 mmetz]:
 > IIUC, the .gislock file is not created under windows because kill() does
 not exist under windows, used by find_process().

 Sort of. The existing code won't work in its entirety on Windows. As
 Windows systems aren't generally multi-user, simply ignoring the entire
 locking issue was the easiest solution.

 > Under Linux, assume the following scenario: a group of people are
 working from different machines on the same location, different mapsets.
 The location is on a network drive accessible by everyone. Now g.mapset
 mapset=othermapset using lock (GIS_LOCK) checks if it could kill the pid
 written in .gislock. But if the pid in .gislock has been written by a
 different machine/system, then the pid in .gislock has nothing to do with
 the pid's available to lock, and the kill()-test is complete moot. Right?

 The purpose of the kill() test is to check whether the .gislock file is
 "stale", i.e. whether the session which created the .gislock file
 terminated without removing it. If kill() fails with ESRCH, the PID stored
 in the .gislock file doesn't refer to an existing process on the local
 system, so the lock is assumed to be stale and is ignored. This test isn't
 particularly reliable; it will consider the lock as stale if it was
 created by a session on another machine, even if that session is still
 alive, and will consider the lock as alive if the session has terminated
 but its PID is now used by another process.

 > Therefore I would suggest to skip the find_process() step and assume
 that a mapset is locked as long as the file .gislock exists.

 That would avoid the issue with the lock file being considered stale due
 to having been created on a different system. OTOH, it would require stale
 lock files to always be removed manually. If that is considered a problem,
 writing a hostname along with the PID would solve the first issue without
 abandoning automatic removal on non-shared filesystems.

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/226#comment:12>
GRASS GIS <http://grass.osgeo.org>