After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 731562 - [IMAPx] Occasionally getting 'Empty cache file' error
[IMAPx] Occasionally getting 'Empty cache file' error
Status: RESOLVED FIXED
Product: evolution-data-server
Classification: Platform
Component: Mailer
3.12.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2014-06-12 10:17 UTC by Milan Crha
Modified: 2014-06-19 14:32 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Milan Crha 2014-06-12 10:17:46 UTC
I've just got "Empty cache file" error in one of my IMAPx folders in 3.12.3.
I selected a message in the folder and the error popped up. Interestingly, selecting any message in that folder, which was not downloaded yet, returned the same error (with different path for the cache file, of course).

Investigating further, the in/out streams on the connections were passing:

   E00370 UID FETCH 701881 (BODY.PEEK[])
   E00370 OK UID FETCH completed

with no body being peeked at all. I went deeper in investigation and it turned out that the UID FETCH can return OK response even when the message doesn't exist in the currently selected folder. Trying to do the UID FETCH in a nothing-selected state yields into an error, NO response about not being in the selected state.

Due to that I suspect that the IMAPx was left in a selected state of another folder than it was asking messages from. Truly, moving away from the folder and back fixed the problem, which kind of supports the hypothesis.
Comment 1 Milan Crha 2014-06-16 13:04:11 UTC
I added locks around CamelIMAPXServer->priv->select_* properties, which seems logic when these are guarded in all other places, but it wasn't it. The problem is that the SELECT is done on demand, before the actual job is run, and it is tight to that particular job. When the job was cancelled, the SELECT command didn't recognize it properly and expected the SELECT command being finished successfully, which led to the error of having selected one folder, but asking for messages in another folder. I fixed it with:

Created commit a24277e & 17c7189 in eds master (3.13.3+) [1]
Created commit 41a795b in eds evolution-data-server-3-12 (3.12.4+)

[1] https://git.gnome.org/browse/evolution-data-server/commit/?id=a24277e
    https://git.gnome.org/browse/evolution-data-server/commit/?id=17c7189