Thanks for the info. Just a reminder, any problems I had could be
related to the fact that I was looking at the wrong reports...
Patrick Ohly wrote:
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.
Yes, there needs to be something and that something needs to be
available after the fact, so the UI can tell if automated syncs have
failed for some reason. I was really hoping the reports could be the
single source of info I could use but I do see your point...
Doesn't this same problem appear when you automatically sync e.g. 20
times a day, and there are no changes?
Could this work: syncevolution creates a report for every sync, but
before saving, it compares it to the last saved report. If they appear
to be the same (with certain rules), do not save a new report but update
the old one.
This way we could "compress" a group of syncs that fail in the same
exact way into one report. Likewise a group of syncs that have no
changes in either end.
We'd need a "duplicate-count" key and possibly some new time keys (times
for first and last sync in the series?).
- Jussi
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
