[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:13 mmetz]:

 > How about avoiding PID altogether and writing 'user at host' to .gislock?
 That places the burden of determining whether or not the lock is stale
 entirely on the user, as there's no mechanism (even an unreliable one) for
 determining whether the session which created the lock file is alive.
 Writing pid at host would solve the shared-filesystem issue insofar as it
 lets etc/lock know whether the kill() test can be used. If the lock file
 was created by a session running on a different system, there's no
 portable way to determine whether the session is still alive. However,
 displaying the PID and host to the user may allow them to make the
 determination manually.

 > Currently, in trunk, the wxGUI asks at startup if an existing lock
 should really, really be removed. Starting trunk in text mode silently
 removes any gislock (needs to be fixed).
 It shouldn't remove the lock file. It should only re-write the lock file
 if the PID contained within doesn't match that of an existing process on
 the local system. etc/lock terminates with an exit code of 2 if the
 .gislock file exists and the PID contained within matches an existing
 process, an exit code of 1 if an error occurred (e.g. couldn't create the
 file or couldn't write to it) and an exit code of 0 if the file was
 written successfully.

 > How about a new flag for yes-I-know_what-I'm-doing to try to force
 remove an existing lock both at startup and for g.mapset?
 In practice, stale lock files are sufficiently rare that it's debatable
 whether it's worth the effort of adding a simpler alternative to manually
 deleting the lock file.

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