On Fr, 2010-02-19 at 11:49 +0000, Patrick Ohly wrote:
On Fr, 2010-02-19 at 08:00 +0000, Jussi Kukkonen wrote:
> I'm open to improvement suggestions on the error message wording though:
> I'm not too familiar with what exactly all the different error codes
I think we are all learning about this. Let's see what the reason was in
this particular case.
A segfault. SyncEvolution core prepares for that by recording a bad
result for the session, which has to be overwritten later on:
synchronization process died prematurely
/** command failed / fatal DB error */
STATUS_FATAL = 500
That was introduced before we started to distinguish between local and
remote errors. The error code should have been 500 + LOCAL_STATUS_CODE
to mark it as a local problem.
> As an example, should we emphasize that this "db
> reported by the peer (so not a local db problem)?
Distinguishing between local and remote errors would be useful,
independently of this particular error. It is a first hint to the user
who he should contact for help, or whether the problem might go away
(remote failures might get fixed by the server admins, local ones
require some action by the user).
> Are there any common
> fixes we could suggest in the message?
Nothing comes to my mind right now.
In this particular case, should we introduce a special status for "died
prematurely"? Like a new SyncEvolution specific STATUS_DIED_PREMATURELY
There is something in syerror.h:
/** base code for linux signals (SIGXXX). SIGXXX enum value will be
added to LOCERR_SIGNAL */
LOCERR_SIGNAL = 20500
But we cannot use that because we should better not try to overwrite
status.ini after the process went bad because of a signal.
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.