[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Please update Akonadi 1.12 packages



Hello!

I know Akonadi 1.12.0 is still just in experimental, but please consider
updating to 1.12.1 with the following fix

commit 4ca8b846baaad48ebbd723f6411f9571a3b0f5ad
Author: Dan Vrátil <dvratil@redhat.com>
Date:   Tue Apr 22 11:28:07 2014 +0200

    Remove the invalid GID part from PartTable before starting PartTable migration
    
    More people than we expected have invalid 'GID' part in their PartTable,
    which breaks migration to schema 25, because it expects all part types
    to have a valid name.
    
    To work around this fact, we DELETE all parts with name 'GID' from PartTable
    before starting the actual migration. This will not fix the migration for
    people with other invalid parts, but I haven't heard of any such. To make
    this completely bullet-proof, we would need to iterate through all entries,
    which would be massively slower than current INSERT INTO ... SELECT FROM approach.
    
    Distributions, this is a good choice for backporting into 1.12.1 ;-)
    
    BUG: 331867
    FIXED-IN: 1.12.2


Cause of some bugs in 1.12.0 including this data loss one:

commit ff9edf8c0d96b179116558020d5a571a25142795
Author: Dan Vrátil <dvratil@redhat.com>
Date:   Sat Apr 5 23:29:12 2014 +0200

    Fix potential severe data loss during copy and move operations
    
    Move and copy operations on larger sets of items can take some time, because
    we need to make sure that all items have full payload stored in Akonadi. This
    is necessary especially with local resources, like maildir, which have cache
    timeout set to 5 minutes (after that all their payload is removed from Akonadi
    and is fetched from HDD on demand, because it's cheap, fast and does not
    unnecessarily duplicate emails in maildir and in database). However fetching
    large amount of items via ItemRetriever takes a lot of time, sometimes it can
    take even more than 5 minutes. And in such case there is a very high chance,
    that the CacheCleaner will just remove the newly cached payloads from Akonadi
    again and so when ItemRetriever finishes, many items have empty payload in
    Akonadi again. ItemRetriever nor handlers are aware of this howerver, so they
    will just make copies or moves of empty items, causing data loss.
    
    This patch introduces CacheCleanerInhibitor, a class which when it is created
    will pause the timer in CacheCleaner and resume the timer again when it's
    destroyed (so usually when it goes out of scope). Also, this patch adds the
    inhibitor to all handlers that use ItemRetriever, so that the the situation
    described above does not happen.
    
    The current solution is not perfect because it pauses the entire CacheCleaner
    while I think it would be better to be able to temporarily 'blacklist' only
    specific collections or items. That would however require much more complex
    code and changes, which makes it unsuitable for 1.12 release.
    
    I tried moving 78 000 emails from one maildir to another and all emails were
    moved correctly. Move itself has many other problems (CPU, IO, memory, KMail
    responsivness, etc.) but that's out of scope of this fix.
    
    CCBUG: 330895



As well as

[Akonadi] [Bug 332953] New: "maildir: Not supported type" popup on mail receive:  "Unable to deserialize payload part"
https://bugs.kde.org/show_bug.cgi?id=332953


I think I will compile myself now again to make sure these bugs are gone.

Thank you,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7


Reply to: