[GRASS-dev] Re: [GRASS GIS] #755: trying to start in mapset you don't own gives wrong error msg

[GRASS GIS]

#755: trying to start in mapset you don't own gives wrong error msg
----------------------+-----------------------------------------------------
  Reporter:  hamish   |       Owner:  grass-dev at lists.osgeo.org
      Type:  defect   |      Status:  new                      
  Priority:  minor    |   Milestone:  6.4.0                    
 Component:  default  |     Version:  svn-develbranch6         
Resolution:           |    Keywords:  mapset access            
  Platform:  Linux    |         Cpu:  x86-32                   
----------------------+-----------------------------------------------------
Comment (by glynn):

 Replying to [ticket:755 hamish]:

 > if I do "chmod 999.999 $LOCATION/user1" to make my user account not the
 owner of a mapset,

 Do you mean "chown"?

 > and then start grass with the full path to the mapset I get this error:
 >
 {{{
 $LOCATION/user1/.gislock: Permission denied
 ERROR: $GISBASE/etc/lock:
 hamish is currently running GRASS in selected mapset (file
 $LOCATION/user1/.gislock found). Concurrent use not allowed.
 }}}

 Making wild guesses as to the cause of a failure then presenting such
 guesses as facts is a common problem in GRASS. Unfortunately, I my
 experience suggests that this isn't going to change any time soon.

 > user1 is drwxr-xr-x, so the Permission denied comes from the fact that
 etc/lock can't write the .gislock file, not that my current user account
 already has a copy there. (I checked, the file doesn't exist)

 If etc/lock fails with an exit code of 1 (which is what you get if it
 calls G_fatal_error()), etc/Init.sh prints the above message. The possible
 reasons for an exit code of 1 are:

  1. Wrong number of arguments or the second argument isn't a valid
 integer.
  2. Lock file exists, contains a PID, and kill(pid, 0) either succeeded or
 failed for a reason other than ESRCH.
  3. Lock file creation failed.
  4. Writing the PID to the lock file failed.

 For 1, 3, and 4, it also generates an error message.

 It cannot fail with an exit code other than 0 or 1.

 > So that Permission denied needs to be better caught I guess.

 Either etc/Init.sh needs to be changed to print e.g. "failed to create
 lockfile" rather than making unsubstantiated claims as to *why* lockfile
 creation failed, or etc/lock needs to be changed to provide information as
 to why it failed.

 > or improve  G!__mapset_permissions() or G!__mapset_permissions2() and
 it's a case of the error message being a bit too overenthusiastic?

 Those functions aren't used by etc/lock.

 Also, those functions don't print error messages, they just return a
 status code: 1 for success, 0 for found but not owned by the current user,
 -1 for couldn't stat() or isn't a directory.

 Any error message is printed by G!__gisinit(): "permission denied" for 0,
 "not found" for -1. Those messages are reasonably accurate, although
 someone who is used to standard error messages (perror()) may be mislead
 by the similarity with the standard messages for EPERM and ENOENT
 respectively.

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/755#comment:2>
GRASS GIS <http://grass.osgeo.org>