Re: OfflineIMAP + Wanderlust

[John Goerzen <jgoerzen@xxxxxxxxxxxx>]

On Wed, May 17, 2006 at 11:06:08PM +0100, David Wallin wrote:

> I have a problem with OfflineIMAP used with the MUA Wanderlust (WL).
> Or so I think, anyway.

First, a quick question.  From reading the description of WL, it seems
it is designed specifically for IMAP users and has an offline cache
mode.  So why are you even bothering with OfflineIMAP? ;-)

Second, an option.  You could run a local IMAP server and point both
OfflineIMAP and WL to it.

> I sync emails from an IMAP server (hence the use of OfflineIMAP).  New
> mails end up in .INBOX on my local machine, WL then sorts the mails
> into .INBOX.foo, .INBOX.bar and so forth. 

Really, this sort of filtering should happen on the server if possible.

> When WL moves a mail from .INBOX to .INBOX.foo, it renames the file.

That ideally would not happen, but it doesn't hurt anything.

> When OfflineIMAP syncs the local changes with the IMAP server, those
> mails that have been moved & renamed, are renamed again (right?).

OfflineIMAP will actually issue a delete command to the server and then
re-upload the message in the new folder, but the effect is the same.

> This causes a problem when I edit a message and offlineimap runs in
> the background. Since this message is renamed during the time I write
> my reply, WL gets confused when it tries to set the 'Answer' flag on
> the original email.

I'd say that's a bug in WL -- all sorts of things in Maildirs are based
on filenames, including flags...  it sounds like simply pulling up the
folder in mutt could cause it problems...

OTOH, it is never possible to entirely eliminate this problem with
Maildirs.  The only other option is to add a header to a message, which
I think is even more dangerous.

> My guess is that the problem isn't really anyones fault (except mine
> for insisting on having this setup), but is the renaming necessary on

Not really, though WL could probably be improved.

> OfflineIMAPs part? Could it be optional?

No; it must have a way to store the UID of each message locally to
ensure correct, exact synchronizations.

-- John