On Wed, 2009-12-02 at 20:48 +0000, Jussi Kukkonen wrote: > It seems that at least some failing syncs do not generate a report: I > tried setting a wrong password and syncing. When I asked for a report > afterwards, I got the one for the last successful sync. Is this what I > should expect?
If the sync session fails early enough, then it doesn't get to the point where a report is generated. Otherwise every single attempt to run a sync with an invalid configuration would create a report, eventually causing "useful" reports and their backups to be expired (maxlogdirs, MB#7708). So yes, I think this is expected. I'm not entirely sure which D-Bus call reports such failures and how, but there should be something. > The GetReports BNF documentation was very good for writing the parser, > but I'm still a bit confused about some of the fields: Right, we need to add some more semantic information. > * status > Only value I've seen is 200, and git log tells me this is a successful > sync. Does this otherwise correspond to error in StatusChanged? Yes, it should. > * source-X-status > This seems to be '0' all the time. I assume this correponds to error > values in sources hash in StatusChanged signal? Yes. > * source-X-mode > This was "two-way" even when I set "none" for this source. That needs to be fixed. > * source-X-resume > ? The sync done by that source resumed a suspended sync. There's no way to determine whether a source was suspended during the last sync, because the Synthesis engine doesn't provide that information. Could be added, I suppose. -- 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. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
