GNOME Bugzilla – Bug 729848
[IMAPx] Hard to get to cached messages in offline
Last modified: 2014-11-05 02:52:05 UTC
Created attachment 276207 [details] screenshot This reminds me a bit of bug #703975... except that this time Evolution "knows" the network is unavailable, but still tries to access the message online instead of getting it from the cache. Evolution is set to automatically download/cache my messages, at least for my inbox folder, so I'm quite certain that the message actually is in the cache. What I get when trying to read any message while wifi is turned off is this: > Unable to retrieve message. > Error resolving 'imap.gmail.com': Name or service not known Not having access to my messages offline defeats the purpose of why I use IMAP/an email client.
Thanks for a bug report. What is your exact evolution-data-server version, please? I believe you are before commit [1], which landed for 3.12.2. Messages downloaded with 3.12.2 should never leave the cache. [1] https://git.gnome.org/browse/evolution-data-server/commit/?id=a075969d782d
Oh, indeed, the version in hughsie's COPR is 3.12.1.
Okay nope, I'm still seeing this in Evolution+EDS 3.12.2 from hughsie's updated COPR. Even messages that I read five minutes ago when I was online in my inbox... once I restart evolution while offline, I am not ever able to read them until I come online. Likewise, I even get the same error about the host not being "resolvable" when right-clicking a folder and selecting "Properties" while offline (while online, I don't get an error, I get bug #730979 instead :) ...
Aah, I see, it is a different kind of error. Created commit 95564f1 in eds master (3.13.3+) [1] Created commit 44fd7a2 in eds evolution-data-server-3-12 (3.12.4+) [1] https://git.gnome.org/browse/evolution-data-server/commit/?id=95564f1
*** Bug 730757 has been marked as a duplicate of this bug. ***
Okay, I had forgotten that this bug was marked as fixed and thought it was still open, so I did some more retesting tonight because I was definitely sure (from my daily use) that it wasn't fixed... it turns out that it is a sub-portion of the behavior that is broken, so I filed a follow-up as bug #739650. I hope that one is clearer :)