From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/85785 Path: news.gmane.org!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.gnus.general Subject: Re: Gnus Own-Cloudy? Date: Sat, 14 Feb 2015 21:48:01 +0800 Message-ID: <874mqomwoe.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1423927361 32069 80.91.229.3 (14 Feb 2015 15:22:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 14 Feb 2015 15:22:41 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M34024@lists.math.uh.edu Sat Feb 14 16:22:28 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 1YMeY4-0001kW-UP for ding-account@gmane.org; Sat, 14 Feb 2015 16:22:25 +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 1YMeXI-0005Js-HB; Sat, 14 Feb 2015 09:21:36 -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 1YMd4x-0004xC-FH for ding@lists.math.uh.edu; Sat, 14 Feb 2015 07:48:15 -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 1YMd4w-0003ZB-8A for ding@lists.math.uh.edu; Sat, 14 Feb 2015 07:48:14 -0600 Original-Received: from plane.gmane.org ([80.91.229.3]) by quimby.gnus.org with esmtp (Exim 4.80) (envelope-from ) id 1YMd4q-00022p-Us for ding@gnus.org; Sat, 14 Feb 2015 14:48:08 +0100 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YMd4p-0001lA-8p for ding@gnus.org; Sat, 14 Feb 2015 14:48:07 +0100 Original-Received: from 114.248.19.180 ([114.248.19.180]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Feb 2015 14:48:07 +0100 Original-Received: from eric by 114.248.19.180 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Feb 2015 14:48:07 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 60 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 114.248.19.180 User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) Cancel-Lock: sha1:yUsLbY2bfUpi3Bwy+/fQwSX13cM= 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-363--24064h-0s--0d--mailman, 0.000-27--1729h-0s--0d--default, 0.000-16--1057h-0s--0d--server, 0.000-16--1040h-0s--0d--flags, 0.000-16--1007h-0s--0d--uid Spam tokens: 0.989-2253--150h-1091s--0d--HTo:D*gnus.org, 0.988-2387--170h-1161s--0d--H*RU:quimby.gnus.org, 0.988-2387--170h-1161s--0d--Hx-spam-relays-external:quimby.gnus.org, 0.987-2365--192h-1161s--0d--H*RT:80.91.231.51, 0.987-2365--192h-1161s--0d--H*RT: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 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 SPF_PASS SPF: sender matches SPF record -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 1.2 RCVD_NUMERIC_HELO Received: contains an IP address used for HELO 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -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:85785 Archived-At: 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. That's what I'm guessing, anyway! Hopefully I'll get a little closer tomorrow. > [1]: http://sourceforge.net/p/isync/mailman/message/33402006/