On Thu, 2009-12-03 at 09:19 +0000, Jussi Kukkonen wrote:
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...
And I see your's ;-) It is indeed reasonable to expect a report even for
failed attempts to start a sync. It just hasn't been necessary so far.
Doesn't this same problem appear when you automatically sync e.g.
20
times a day, and there are no changes?
Yes. I consider "more intelligent database dumping" a blocking issue for
automatic sync.
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.
That could work. We can limit this kind of compression to syncs which
fail to start and then use the first "ERROR" line as criteria for "same
problem as last time".
We'd need a "duplicate-count" key and possibly some new
time keys (times
for first and last sync in the series?).
Agreed. I'll have a look at implementing this.
--
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.