On Thu, 2010-03-18 at 14:05 +0000, Lukas Zeller wrote: > Hello Patrick, > > On Mar 18, 2010, at 14:00 , Patrick Ohly wrote: > > > On Tue, 2010-03-16 at 14:40 +0000, Lukas Zeller wrote: > >> Most probably, there should be an extra check for that "too late" > >> suspend. > > > > Your patch in the "luz" branch works, thanks a lot. > > Thanks for the feedback. After pushing I suddenly had the impression > it could still be wrong for another case, I have to follow that > thought first to make sure. So that's why I did not announce the patch > out loud...
It has passed all of my tests, so I'll go ahead and use this in the next SyncEvolution snapshot. If you have more thoughts on what I should test, please let me know. > > But it would be nice if this could be checked already before running > > that next sync. Is there a possibility to retrieve the "datastore is > > suspended" information from a binfile-based client? Is it possible in a > > server? > > In both cases, it's the resumeAlertCode target field. If it is not > zero, the datastore is resumable - i.e. a client will try to resume > and a server will accept a resume. > In binfile based setups, you can use > the /profiles/xx/targets/<dbid>/resumeAlertCode settings key to access > that value. In "both cases" - there are no targets in a server, so how would that work there? I suppose it is part of the admin data, but that is internal and and peeking inside it would bypass the official API. -- 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. _______________________________________________ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
