+++ This bug was initially created as a clone of Bug #970013 +++

Description of problem:

Version-Release number of selected component (if applicable):
evolution-2.32.3-1.el6.x86_64

How reproducible:
always

Steps to Reproduce:
1. set up existing IMAP+ account in evolution
2. set up the account to "automatically synchronize remote mail with local"
3. in File menu, hit "download messages for offline use"
4. put evo in offline mode
5. select some message you didn't select before

Actual results:
the message can not be viewed as it wasn't downloaded

Expected results:
the message is downloaded during mail synchronization after step 2. or explicit request to download it after step 3.

Additional info:
This also breaks full-body search in messages...

This bug would be regression from 2.28 behaviour (with IMAP account)

--- Additional comment from Milan Crha on 2013-06-03 11:38:22 EDT ---

I cannot speak for imap+, it's too new in 2.32.3, from my point of view, but the old imap provider caches only newly recognized messages, if the option is set. That means that old messages are not affected by the option. Also, it might not do much with File->Download for offline, because the messages are scheduled for download when they are recognized as new.

--- Additional comment from David Jaša on 2013-06-03 12:01:43 EDT ---

The old imap provider at least downloaded the messages when full-body search was invoked on top of the folder, that doesn't work either in imap+/2.32. Maybe worth of a separate bug.

Side question related to searches - when caching is not enabled, is the message indexed locally when downloaded for reading so that it can be searched in the future quickly even when not in cache?

--- Additional comment from Milan Crha on 2013-06-03 15:11:32 EDT ---

(In reply to David Jaša from comment #2)
> The old imap provider at least downloaded the messages when full-body search
> was invoked on top of the folder, that doesn't work either in imap+/2.32.
> Maybe worth of a separate bug.

The old IMAP does server-side searching, downloading whole folder is impractical for various reasons. Thinking of it, maybe the "File->Download for offline" is there to get copy of the server content locally (I should check the code, of course). I would not use it myself, because I have really many messages (one folder has more than 110K messages), but I agree that it has its use-cases as well.

> Side question related to searches - when caching is not enabled, is the
> message indexed locally when downloaded for reading so that it can be
> searched in the future quickly even when not in cache?

Yes, once you view the message it's stored in a cache and the next time anything asks for the message (can be also a search), the message is taken from cache.

--- Additional comment from Milan Crha on 2013-06-04 14:16:35 EDT ---

A quick look in the code, I see both imapx and imap provides use the same mechanism to fetch messages for offline, which depends on notifications about newly recognized messages. The quick code review didn't show anything obviously broken, though the imapx code isn't one of the simplest.

With respect of File->Download message for offline, this checks all folders which were opened so far (includign initial message check), and makes sure each message is downloaded in these folders). The tricky part is that the folder should be in the store's 'folders' bag, to be considered for offline, and that either the store or the folder has "sync for offline" set. You indicated above that you have one of the options set, though.

--- Additional comment from Milan Crha on 2013-06-04 14:30:40 EDT ---

OK, I tested this on my local machine, and the messages are downloaded for offline for me, when keeping in mind restrictions in comment #4, basically with an individual folder on which I set to copy content for offline, and using File->Download for offline downloads all missing messages from that folder. There is one restriction, when changing setup of the account (including "Automatically synchronize remote mail locally") requires restart of evolution to take into effect properly. (Restart of evolution is a known limitation.)

I'm wondering whether either QResyn, or IDLE support of imapx is not doing trouble here. Could you try to disable "Use Quick Resync if the server supports it" and "Use I_dle if the server supports it" on your imapx account, restart evolution and wait whether it'll work, please? I have these options disabled here.

In any case, I would prefer to disable imapx in the rebase, it's not in a good shape in 2.32.3.

--- Additional comment from David Jaša on 2013-06-04 14:45:11 EDT ---

(In reply to Milan Crha from comment #5)
> ...
> I'm wondering whether either QResyn, or IDLE support of imapx is not doing
> trouble here.

I disabled just Quick Resync and the sync seems to go just fine (let's see in few hours :)).

> In any case, I would prefer to disable imapx in the rebase, it's not in a good
> shape in 2.32.3.

Well, support for IDLE is one of the biggest positives of 2.32 over 2.28...

--- Additional comment from Milan Crha on 2013-06-04 15:14:43 EDT ---

If it's really about QResync, then Matthew did some changes for this, in series of ~3 commits, beginning at [1], but the code is too different to just backport the changes. I'd rather think of disable and hide QResync (if you want the IDLE, even in not-so-polished imapx provider).

[1] https://git.gnome.org/browse/evolution-data-server/commit/?h=gnome-3-8&id=fe53fde76b9521638b57e28250de8af16e58d206

--- Additional comment from Matthew Barnes on 2013-06-04 16:24:15 EDT ---

The quick resync issue turned out to be a legitimate Zimbra bug.

http://bugzilla.zimbra.com/show_bug.cgi?id=82493

I only worked around it as best I could.

--- Additional comment from David Jaša on 2013-06-06 12:38:49 EDT ---

Even with quick resync disabled, the issue is not fully resolved:

First and foremost: when the folder downloading fails during Evo run time, hitting "Download messages for offline use" has no effect anymore (in spite of messages still lacking their bodies)

Second, the messages are downloaded from oldest to newest, the order should be reverse (usually the most recent messages are more relevant and by extension, more worthy to bother with caching them)

Third, the messages are downloaded in from one-folder at time, with no particular folder order. Download order based purely on message age across the whole account would be way better
(it would be perfect if user could ask evo to download and keep messages cached per folder or to select levels of caching - headers/bodies/attachments - but I guess that that would be more of RFE, while the points decribed here look like clear bugs to me).

--- Additional comment from Milan Crha on 2013-06-24 09:01:01 EDT ---

I'm moving this to evolution-data-server, because the IMAPx code resides there.