More stack traces
Sebastian at SSpaeth.de
Fri Sep 9 10:18:04 BST 2011
On Thu, 8 Sep 2011 22:28:21 +0200, Nicolas Sebrecht wrote:
> > In
> > .offlineimap/Account-WHATEVER/LocalStatus/Lists.WG21.Reflector
> > You should find the UID 94 and simply delete the line, it will lead a
> > one duplicated message at worst. If you are using the sqlite backend,
> > the sqlite3 database is in:
> > .offlineimap/Account-WHATEVER/LocalStatus-sqlite/Lists.WG21.Reflector
> What about implementing such work ourself?
Yes, it would be good if we could offer the user more help in how to
sort out such corruptions. On the other hand, before I invest time in
those plain text files, I would rather work towards including the UID
mapping in our sqlite status database. We could either add another
column to LocalStatusCache table called 'MappedUID' or 'LocalUID'. Or we
could store the REMOTEU_UID -> LOCAL_UID Mapping in another 'UIDMapping'
table in the same sqlite db.
It might be unfounded, but I have more trust in a simple sqlite UPDATE
or INSERT command than in writing out all of our cache file completely
for each change.
This would be the first step to avoid corruption. As a second step we
should offer some "sanity check mode" in which the databases are checked
for consistency and help is offered as to how to fix inconsistencies.
As a third step, I would love to implement a "UID Mapping restoration"
mode which would analyze the content of mails and help to recreate the
UID Mapping if the cache is corrupted or has been lost. THis way we can
recreate the cache.
Personally, I don't use IMAP<->IMAP, so it has never been high up on my
radar. I would love to have SSL cert verification, the --info mode and a
--dry-run mode first. If nobody beats me to it, I'll have a look at the
UID mapping part afterwards.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: not available
More information about the OfflineIMAP-project