[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 hamish):

 > Replying to [ticket:755 hamish]:
 >
 > > if I do "chmod 999.999 $LOCATION/user1" to make my user
 > > account not the owner of a mapset,

 Replying to [comment:2 glynn]:
 > Do you mean "chown"?

 yeah

 > > 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.

 In this case it seems that something is wrong in lock.c, the above message
 should only be presented when the lock file does exist and the value in it
 matches a current PID. So not so wild a guess after all.

 The alternate failure error which alone should have been triggered gives
 some handy suggestions about why you might get a filesystem error but
 doesn't state as fact why it happened.

 quoth:
 {{{
     locked = 0;
     if ((lock = open(file, 0)) >= 0) {  /* file exists */
         G_sleep(1);             /* allow time for file creator to write
 its pid */
         if (read(lock, &pid, sizeof pid) == sizeof pid)
             locked = find_process(pid);
         close(lock);
     }
     if (locked)
         exit(1);

     if ((lock = creat(file, 0666)) < 0) {
         perror(file);
         G_fatal_error("%s: ", argv[0]);
     }
     if (write(lock, &lockpid, sizeof lockpid) != sizeof lockpid)
         G_fatal_error("%s: can't write lockfile %s (disk full?
 Permissions?)",
                       argv[0], file);
     close(lock);
     exit(0);
 }}}



 > 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.
 ...
 > It cannot fail with an exit code other than 0 or 1.

 do you mean that as strict policy, or interpreting what was seen in the
 code?


 > or etc/lock needs to be changed to provide information as to
 > why it failed.

 For now in trunk I've modified lock.c to exit with code 2 if the lockfile
 validly exists, absolving the init.sh error message and freeing exit code
 1 to indicate a generic error.


 Hamish

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