See libsoup bug 732087.

(cherry picked from commit 6a2b8736)

The first patch caused server-side searching also for cases where all
data were available locally, which made searching slower. This tests
first if everything in match-all is available locally, and if so, then
it uses local search, rather than the server side.

Couple things changed here:

a) the camel_folder_summary_get_changed() could return list of changed
   messages only if they were loaded in memory, which is not correct - I
   think it's part of the issue why it failed

b) it could happen that imapx_server_sync_changes() was called to save some
   changes, but then didn't change anything; in such cases, messages marked
   as locally changed were never unmarked, which led to false tests; I added
   a function to unmark the messages as locally changed (this can cause slow
   close of evolution for the first time, due to unsetting of the flag, but
   later ends are fine)

c) state of the message flags on the server is the master state, except of
   the state where locally stored info is marked as locally changed. This
   allows to show proper state of messages on the server (it is influenced
   by a) and b) too, so it might take up to two evolution starts to get
   the same view in evolution as is the state on the server)

d) do not use CamelOperation in the parser thread, because it can be
   cancelled at an application end with camel_operation_cancel_all() call,
   which is done too early, before any pending jobs are properly finished
   (it can be IDLE job, or save of folder changes back to the server)

The code was surely trying to avoid writing CAMEL_IMAPX_MESSAGE_RECENT
flag back to the server, but the actual behaviour was that each flag
had been ignored, if the CAMEL_IMAPX_MESSAGE_RECENT was set.
This could have an effect of copied read message being marked as unread
in the destination IMAPx folder.

Mailbox names containing a '+' character were tripping up the parser due
to it being treated as one of a special set of characters to distinguish
identifiers from IMAP syntax.  But I don't think '+' is necessary in the
set of characters.  For continuations, at least, it should always follow
a newline character, with is also a special character.

(cherry picked from commit 34f0f99f)

This may prevent any network background operations, when associated
CamelSession is offline, like when the machine gets suspended or is
just resumed.

If there is a newer version installed, then use it, rather than
the old.

This change addresses:
- typo for GDestroyNotify (was being used ref, instead of unref)
- leaking data_cal object when opening a calendar
- DataCalView dispose didn't remove view from the backend

These led to memory leaks on both view and backend objects.

The SEARCH command doesn't support all the things evolution can
search for, but it can cover the most common cases, which speeds
searching significantly (especially when the folder content is not
required locally).

Two threads could call initialize_backend() simultaneously,
overwriting data one to the other, which caused the crash.

Lubomir Rintel authored Jan 09, 2014 and Matthew Barnes committed Jan 09, 2014

A broken IMAP server (whatever they use at Masaryk University) was
seen having this conversation:

  C: A001 UID FETCH 1:* (RFC822.SIZE RFC822.HEADER FLAGS)
  S: * 1 FETCH (RFC822.SIZE 4220 BODY[HEADER] {523} ...)
  ...

This confuses Camel into thinking it was a request for a full message
and it in turn fails to update the folder summary and issues a warning
about not being able to locate an appropriate FETCH job.

This works around the issue by treating BODY[HEADER] as equivalent to
RFC822.HEADER in untagged FETCH responses.

(cherry picked from commit 7b0b0de9)

William Jon McCann authored Dec 18, 2013 and Matthew Barnes committed Dec 18, 2013

(cherry picked from commit aa864860)

(cherry picked from commit ed63961a)

Camel likes to use this debugging idiom:

  #define d(x)

and then wraps debugging statements like so:

  d (printf (...));

One is supposed to enable debugging by changing the macro to:

  #define d(x) x

This idiom makes debugging statements hard to grep for, but moreover
they don't get compiled regularly and so they tend to bit rot.

As was the case in CamelGpgContext, where the debugging statements
didn't build because they were still written for Camel's old home-
grown object system.

(cherry picked from commit 44dec69c)

Camel likes to use this debugging idiom:

  #define d(x)

and then wraps debugging statements like so:

  d (printf (...));

One is supposed to enable debugging by changing the macro to:

  #define d(x) x

This idiom makes debugging statements hard to grep for, but moreover
they don't get compiled regularly and so they tend to bit rot.

As was the case in CamelStreamFilter, where the debugging statements
didn't build because they were calling CamelStream functions as they
existed YEARS ago.

(cherry picked from commit 5088aefa)

camel_imapx_job_take_error() was being called twice on the same GError.
The 2nd call freed the GError set in the 1st call, which corrupted the
memory.  Put a safeguard in camel_imapx_job_take_error() to catch this
in the future.