Red Hat Bugzilla – Bug 978525
CamelSession's network-available never set to TRUE, only to FALSE
Last modified: 2014-01-02 04:08:26 EST
+++ This bug was initially created as a clone of Bug #970013 +++
Description of problem:
Version-Release number of selected component (if applicable):
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
the message can not be viewed as it wasn't downloaded
the message is downloaded during mail synchronization after step 2. or explicit request to download it after step 3.
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 , 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).
--- 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.
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.
Hrm, the change for the offline caching touches both evolution and evolution-data-server, the evolution's fault is that it only sets CamelSession's network-available to FALSE, but never to TRUE (still in upstream too, on 3.9.3). I left the eds bug for backport of Matthew's QResyc workarounds for a Zimbra bug. The second and the third from the end of the previous comment are more feature requests, which should be addressed upstream first.
Created attachment 765737 [details]
According to steps:
a) have an IMAP or IMAP+ account, on which is set "Automatically synchronize
remote mail locally", or have a folder on which a similar property is set
b) start evolution in online mode
$ evolution --online -c mail
c) go to offline by pressing the lower-left icon on the status bar line, or
File->Work Offline; respond "Do not synchronize", when asked
d) find a folder which does not have all messages downloaded for offline
e) go to online, with the lower-left icon, or File->Work Online
f) click File->Download messages for offline
status bar shows messages being downloaded for offline in current folder (or any other already visited folder)
Note (an implementation detail):
The File->Download for offline, same as synchronize before going offline, works only for already visited folders, it doesn't open folders on its own.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.