help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: From Gnus to mu4e


From: Suvayu Ali
Subject: Re: From Gnus to mu4e
Date: Mon, 31 Aug 2015 02:16:22 +0200
User-agent: Mutt/1.5.23.1 (2014-03-12)

On Fri, Aug 28, 2015 at 08:31:26AM -0700, Ian Zimmerman wrote:
> On 2015-08-28 11:06 +0200, Suvayu Ali wrote:
> 
> > When MUA 2 fails, it is easily handled by reporting to the user and not
> > trying to commit the changes again.  E.g. in mutt, this is handled by
> > telling the user something like: file does not exist (I don't recall the
> > exact phrasing), and keeping the folder state as is.
> 
> I don't know about you, but if I got this blurb from my MUA I would
> first stare at the screen for minutes, repeating "wtf wtf", then (if I
> was having a good day) investigate, and finally mutate the state of my
> computer to ensure exclusive access :-) IOW, I don't want such weirdness
> to happen, whether I call it "race" or not.

Okay, I found the error message, it's cryptic indeed.

  rename: No such file or directory (errno = 2)

IIRC, I did understand it quite immediately when I saw it the first
time.  But maybe it was easy for me because I was quite familiar with
the maildir format, having dealt with OfflineIMAP and I had been
experimenting with Gmail's IMAP implementation to understand how it
works.

Having said all that, I do not think there is any easy solution to this
issue.  This is inherrent in how we are approaching the problem the
moment we choose a solution that relies on syncing rather than being
live (IMAP access).

> And to close the circle, this example in fact has analogy with our
> maildir situation:  the MUA trying to set the "Replied" flag presumably
> just sent off a reply.  So the failure to set the flag means the maildir
> state, while internally consistent, doesn't reflect reality.

This is a very interesting case indeed.  However I do not see any
possible solutions as long as we choose to sync rather than use IMAP.
In this particular case, the inconsistent flags will be corrected on the
next sync, since the remote server has the correct flags.

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]