[GRASS-dev] Re: [GRASS GIS] #755: trying to start in mapset you
don't own gives wrong error msg
GRASS GIS
trac at osgeo.org
Sat Sep 19 14:38:12 EDT 2009
#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 [comment:3 hamish]:
> 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 only thing that's wrong in lock.c is that it doesn't offer any
opportunity for the caller to distinguish between the various ways it can
fail. Its exit code is 0 for success, 1 for any kind of failure.
> > 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?
I mean that there's no way that it can return any other exit 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.
I've updated grass.py accordingly in r39252.
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/755#comment:4>
GRASS GIS <http://grass.osgeo.org>
More information about the grass-dev
mailing list