1. 16 Jun, 2016 1 commit
  2. 24 Jun, 2015 1 commit
  3. 23 Jun, 2015 1 commit
  4. 08 Jun, 2015 1 commit
  5. 31 May, 2015 2 commits
  6. 29 May, 2015 1 commit
  7. 21 May, 2015 1 commit
  8. 27 Aug, 2014 1 commit
  9. 12 Aug, 2014 1 commit
  10. 10 Aug, 2014 3 commits
  11. 31 Jul, 2014 1 commit
  12. 18 Jun, 2014 1 commit
  13. 04 Jun, 2014 1 commit
  14. 03 Jun, 2014 1 commit
  15. 06 Apr, 2014 1 commit
    • Daniel Vrátil's avatar
      Fix potential severe data loss during copy and move operations · ff9edf8c
      Daniel Vrátil authored
      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
      ff9edf8c
  16. 19 Mar, 2014 1 commit
    • Daniel Vrátil's avatar
      Fix search updates in SearchManager · 97bc6c52
      Daniel Vrátil authored
      SearchManager now lives in a separate thread and is using it's own DataStore
      and NotificationCollector. This fixes a crash in MODIFY handler, improves
      performance and does not block the main thread when updating searches (which
      can take a while).
      97bc6c52
  17. 28 Feb, 2014 1 commit
  18. 20 Feb, 2014 1 commit
  19. 17 Feb, 2014 1 commit
    • Daniel Vrátil's avatar
      Wrap all classes in /server to Akonadi::Server namespace · c90b946d
      Daniel Vrátil authored
      Since we now support loading of plugins, having only Akonadi namespace
      might not be enough, as plugins can easily clash (like Akonadi::TagAttribute
      from Akonadi and from kdepimlibs). It will also make it easier to differentiate
      classes once both server and client libs are in the same repo in KF5.
      c90b946d
  20. 05 Feb, 2014 1 commit
  21. 30 Jan, 2014 2 commits
  22. 29 Jan, 2014 1 commit
  23. 05 Nov, 2013 1 commit
    • Guy Maurel's avatar
      coding style · 47f89cf4
      Guy Maurel authored
      REVIEWS: 113592 113593 113594 113610 113611 113612 113613 113614 113615 113616 113618 113619 113620 113621 113622 113623 113624 113626 113627
      47f89cf4
  24. 27 Oct, 2013 1 commit
    • Guy Maurel's avatar
      coding style · 7befc968
      Guy Maurel authored
      REVIEWS: 113470 113469 113468 113467 113466 113465 113464 113463 113462 113461 113460 113459 113457 113456 113455 113454 113453 113452 113451 113450 113449
      7befc968
  25. 21 Aug, 2013 1 commit
  26. 23 Nov, 2012 1 commit
  27. 23 Oct, 2012 1 commit
    • David Faure's avatar
      Don't error out when CollectionModifyJob is simply sending "VIRTUAL 0". · bf164890
      David Faure authored
      If the collection isn't virtual, this isn't a change.
      CollectionModifyJob is simply setting all existing attributes back.
      This fixes CollectionModifyJob, which fixes the imap resource not being
      able to store the uidnext value, so it was constantly re-listing folders.
      (scary, when your inbox disappears, before it reappears...)
      bf164890
  28. 01 Oct, 2012 1 commit
  29. 30 Sep, 2012 2 commits
  30. 22 Feb, 2012 1 commit
  31. 17 Feb, 2012 1 commit
  32. 10 Feb, 2012 1 commit
  33. 17 Jun, 2010 1 commit
  34. 01 May, 2010 1 commit
  35. 25 Apr, 2010 1 commit