From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/85787 Path: news.gmane.org!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.gnus.general Subject: [PATCH] Re: Gnus Own-Cloudy? Date: Wed, 18 Feb 2015 19:12:45 +0800 Message-ID: <878ufv79si.fsf_-_@ericabrahamsen.net> References: <87iofawbcb.fsf@ericabrahamsen.net> <87twyu6s7u.fsf@ucl.ac.uk> <87mw4mukxr.fsf@ericabrahamsen.net> <87wq3qm48q.fsf@ucl.ac.uk> <874mquujf6.fsf@ericabrahamsen.net> <87lhk6kn0y.fsf@ucl.ac.uk> <87iof9tcwc.fsf@ericabrahamsen.net> <87vbj8tv7d.fsf@uwo.ca> <87a90i4c18.fsf@ericabrahamsen.net> <874mqomwoe.fsf@ericabrahamsen.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1424258006 31928 80.91.229.3 (18 Feb 2015 11:13:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 18 Feb 2015 11:13:26 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M34026=ding+2Daccount=gmane.org@lists.math.uh.edu Wed Feb 18 12:13:13 2015 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YO2Z6-0001Ev-DI for ding-account@gmane.org; Wed, 18 Feb 2015 12:13:12 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1YO2Z4-0000Rj-8O for ding-account@gmane.org; Wed, 18 Feb 2015 05:13:10 -0600 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by util0.math.uh.edu with esmtps (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1YO2Z1-0000Rb-D5 for ding@lists.math.uh.edu; Wed, 18 Feb 2015 05:13:07 -0600 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtps (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1YO2Z0-0002hk-5I for ding@lists.math.uh.edu; Wed, 18 Feb 2015 05:13:07 -0600 Original-Received: from plane.gmane.org ([80.91.229.3]) by quimby.gnus.org with esmtp (Exim 4.80) (envelope-from ) id 1YO2Yx-0007jP-8a for ding@gnus.org; Wed, 18 Feb 2015 12:13:03 +0100 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YO2Yv-0001BT-AI for ding@gnus.org; Wed, 18 Feb 2015 12:13:01 +0100 Original-Received: from 111.197.155.109 ([111.197.155.109]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 18 Feb 2015 12:13:01 +0100 Original-Received: from eric by 111.197.155.109 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 18 Feb 2015 12:13:01 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 86 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 111.197.155.109 User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) Cancel-Lock: sha1:36+x5OrrPJyQkC0EsqHTexwzmhk= X-Spam-Score: 0.3 (/) X-Spam-Report: SpamAssassin (3.4.0 2014-02-07) analysis follows Bayesian score: 0.0000 Ham tokens: 0.000-56--3677h-0s--0d--patch, 0.000-39--2541h-0s--0d--PATCH, 0.000-18--1142h-0s--0d--server, 0.000-18--1135h-0s--0d--flags, 0.000-17--1093h-0s--0d--uid Spam tokens: 0.993-5--0h-2s--2d--INBOX, 0.989-2396--151h-1165s--0d--HTo:D*gnus.org, 0.989-2539--170h-1239s--0d--H*RU:quimby.gnus.org, 0.989-2539--170h-1239s--0d--Hx-spam-relays-external:quimby.gnus.org, 0.987-2516--193h-1239s--0d--Hx-spam-relays-internal:quimby.gnus.org Autolearn status: no autolearn_force=no -1.0 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [80.91.229.3 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 1.2 RCVD_NUMERIC_HELO Received: contains an IP address used for HELO -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 2.0 FSL_HELO_BARE_IP_2 No description available. List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:85787 Archived-At: Eric Abrahamsen writes: > Eric Abrahamsen writes: > >> Dan Christensen writes: >> >>> Eric Abrahamsen 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 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