From: Eric Abrahamsen <eric@ericabrahamsen.net>
To: ding@gnus.org
Subject: [PATCH] Re: Gnus Own-Cloudy?
Date: Wed, 18 Feb 2015 19:12:45 +0800 [thread overview]
Message-ID: <878ufv79si.fsf_-_@ericabrahamsen.net> (raw)
In-Reply-To: <874mqomwoe.fsf@ericabrahamsen.net>
Eric Abrahamsen <eric@ericabrahamsen.net> writes:
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Dan Christensen <jdc@uwo.ca> writes:
>>
>>> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>>>
>>>> But I would have thought that the active values for each group are
>>>> stored on disk, so if you don't copy those over as well, Gnus will get
>>>> confused about how many messages are in each group.
>>>
>>> For accessing an IMAP server, there's no need to sync Gnus data. That's
>>> sort of the point of using IMAP for your mail: multiple clients can
>>> independently access it and stay in sync with each other via the IMAP
>>> server.
>>>
>>> Eric S Fraga <e.fraga@ucl.ac.uk> writes:
>>>
>>>> but as you have a local server on each system, they may be numbering
>>>> messages differently depending on how they synchronise with the real
>>>> IMAP server. As a result, the counts and various data structures stored
>>>> within the newsrc.eld file may not be consistent between machines?
>>>
>>> Right. When you are accessing two different IMAP servers (even if
>>> they are synced behind the scenes), you definitely don't want to
>>> sync the Gnus data, since article numbers won't match. For example, if
>>> you tick an article in once Gnus instance, a different article may show
>>> up as ticked in the other.
>
> [...]
>
>> The UIDs seem to remain the same -- at least my earlier ticked messages
>> are the same on both machines. But I'm having another issue with
>> something in my mail chain (gmail <-> isync <-> dovecot <-> gnus)
>> re-setting UIDs for previously received messages, something that I just
>> reported yesterday on the isync mailing list[1].
>
> I've been thinking about this more, and looking at recorded imap
> commands. Here's the records for a message that's getting a new UID:
>
> 14:00:22 [localhost] 1910 SELECT "INBOX"
> 14:00:22 [localhost] 1911 UID FETCH 1:* FLAGS
> 14:00:22 [localhost] 1912 UID FETCH 9975 (UID BODY.PEEK[HEADER])
> 14:00:22 [localhost] 1913 UID COPY 9975 "INBOX"
> 14:00:22 [localhost] 1914 UID STORE 9975 +FLAGS.SILENT (\Deleted)
> 14:00:22 [localhost] 1915 UID EXPUNGE 9975
>
> I have a hunch that's what happening is this:
>
> 1. Gnus gets the new message, tries to split it.
> 2. It doesn't get split, and so falls through to the final default split
> clause, which is "INBOX"
> 3. Gnus moves the message from INBOX to INBOX, then deletes it (see
> above)
> 4. The UID EXPUNGE command interacts badly with something else in my
> mail sync chain, and the message is re-created with a new UID.
This does appear to be what's happening, though I can't claim to be
completely following the full chain of cause and effect. If I refresh
Gnus while I still have unread messages in my INBOX, all those unread
messages get resplit back into the INBOX, with new UIDs.
Somehow (this is the bit I'm unclear about), the \Seen/read state then
gets confused between Gnus and my Dovecot server. Something like: when I
finally mark those messages as read in Gnus, Gnus stores the read status
correctly, but maybe applies the \Seen flag to the previous UID (before
the last round of splitting COPY'ed the message to a new UID), and the
next time I sync, the "real" message is marked as read in Gnus, but not
as \Seen in Dovecot. I've been getting messages like that ever since I
started using IMAP with Gnus.
So there may be a fundamental problem in the way Gnus applies its own
read status, versus \Seen marks on the server. On the other hand, the
simplest solution is probably just to not split messages at all, if they
would be split into the group they're already in. I can think of no
reason to do that. Conserve precious UIDs!
I'm attaching a patch that fixes that. Even if there is a more
fundamental problem, this patch is probably still worth putting through.
I'll run it for a week or so, and unless there's any objection (or
better ideas), push it to master.
Hopefully the end to a long, one-man thread...
Eric
next prev parent reply other threads:[~2015-02-18 11:12 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-10 6:05 Eric Abrahamsen
2015-02-10 9:17 ` Eric S Fraga
2015-02-10 10:20 ` Eric Abrahamsen
2015-02-10 10:48 ` Eric S Fraga
2015-02-10 10:53 ` Eric Abrahamsen
2015-02-10 11:45 ` Eric S Fraga
2015-02-10 15:19 ` Jorge A. Alfaro-Murillo
2015-02-11 2:12 ` Eric Abrahamsen
2015-02-11 11:12 ` Eric S Fraga
2015-02-11 13:48 ` Dan Christensen
2015-02-13 5:26 ` Eric Abrahamsen
2015-02-13 5:52 ` Eric Abrahamsen
2015-02-13 14:57 ` Eric Abrahamsen
2015-02-14 13:48 ` Eric Abrahamsen
2015-02-18 11:12 ` Eric Abrahamsen [this message]
2015-02-10 15:31 ` Jorge A. Alfaro-Murillo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878ufv79si.fsf_-_@ericabrahamsen.net \
--to=eric@ericabrahamsen.net \
--cc=ding@gnus.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).