On Mon, 2010-06-07 at 17:11 +0100, Anssi Saari wrote:
Patrick Ohly <patrick.ohly(a)intel.com> writes:
> Do you have maxlogdirs=0 in your config, as mentioned in a former email?
> Otherwise intermediate sessions may get removed. If the former sync in
> this example did not modify data, then it is not unlikely that it was
Sorry, no, I forgot. But I'm not sure maxlogdirs=0 actually works,
since I seemed to lose some logs regardless.
Are you sure? There's definitely a "if (m_maxlogdirs > 0 )" in the code.
The code which identifies sessions belonging to the current peer is a
bit tricky. Perhaps we unintentionally delete sessions of another peer?
In any case, can you keep an eye on this and try to identify the
situation where a session was removed despite maxlogdirs = 0?
Anyways,, once again. I put up
with two logs.
The first one was slow sync after removing .server.ini from memo and
These logs are still huge. I hate to stress your patience even further,
but can you reproduce the issue with deleting items without giving their
ID to the phone when just syncing one particular data category, like
In the myphone-2010-06-07-18-45 log I see that the phone tried to resume
for calendar+todo, which was refused by the server. I'm a bit confused
that you removed the .server.ini for memo and address book and not the
one for calendar and todo, which (if I remember correctly) had the
incorrect deletion problem earlier.
I think the log shows one peculiarity: forcing a slow sync for "calendar
+todo" is not done, the server falls back from 225 (resume two-way) as
requested by the phone to 200 (two-way) without executing the
I need to check whether that <alertscript> is properly set for "calendar
Lukas, is the <alertscript> perhaps ignored for superdatastores? Why is
the fallback for a resume which cannot be done a normal sync and not a
the second one a two-way afterwards. But it looks like
both memo and addressbook went to slow sync anyway on the second run
Now the phone requests a resume for contacts and memos whereas the
server did not suspend these two data stores.
Overall this looks like an issue with inconsistent error handling. I'm
not sure who is to blame here. My recommendation is to stick to syncing
of only one source at a time. If that fails, then at least no other
sources will be affected.
> I agree that this is something which is not intuitive. Perhaps
> of removing the directory completely, only the .html log file and the
> database dumps should be removed? Then the status.ini documents that
> there was a session and what was done without costing disk space.
Seems reasonable to me.
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.