Bug 53773

Summary: expiring session dirs: error handling
Product: SyncEvolution Reporter: SyncEvolution Community <syncevolution-issues>
Component: GTK UIAssignee: SyncEvolution Community <syncevolution-issues>
Status: RESOLVED MOVED QA Contact:
Severity: enhancement    
Priority: medium CC: syncevolution-issues
Version: unspecified   
Hardware:    
OS:    
Whiteboard:
i915 platform: i915 features:

Description Patrick Ohly 2012-08-19 18:56:45 UTC


---- Reported by jingke.zhang@intel.com 2010-04-19 20:15:49 +0000 ----

This is from http://bugzilla.moblin.org/show_bug.cgi?id=9776

   Description  From  pohly   2010-02-19 08:51:47 PST   (-) [reply]

Right now, any kind of exception thrown inside LogDir::expire() will abort the
function. It gets caught in the general exception handling code and is
reported.

The problem is that the exception might be thrown each time we attempt to
remove old sessions, thus preventing any kind of automated removal of them. The
error reporting doesn't mention that.

One way to trigger such a situation is this:
- sync twice, without making changes
- in the first session, remove a ".after" dump
- continue syncing

This should lead to haveDifferentContent() failing to read the content of the
first session and an error message like:

Data modified locally during synchronization:
*** vcard30 ***
no changes

[ERROR]
/home/pohly/.cache/syncevolution/scheduleworld__1@client_+test_+1-2010-02-08-10-28/ical20.after:
No such file or directory

We should introduce some kind of exception handling in expire() and cope with
failures more gracefully. The exact kind of handling needs to be determined.



--- Bug imported by patrick.ohly@gmx.de 2012-08-19 20:56 UTC  ---

This bug was previously known as _bug_ 1019 at https://bugs.meego.com/show_bug.cgi?id=1019

Unknown platform unknown. Setting to default platform "".
Unknown operating system unknown. Setting to default OS "".

Comment 1 GitLab Migration User 2018-10-13 12:41:25 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/SyncEvolution/syncevolution/issues/64.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.