From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/72808 Path: news.gmane.org!not-for-mail From: Michael Welsh Duggan Newsgroups: gmane.emacs.gnus.general Subject: Re: Returning to ticks on read-only imap servers Date: Sat, 09 Oct 2010 04:10:33 -0400 Message-ID: <871v7zss5i.fsf@maru.md5i.com> References: <87eic45u1n.fsf@maru.md5i.com> <8762xdsn0d.fsf@maru.md5i.com> <87zkuozgr5.fsf@keller.adm.naquadah.org> <87vd5czggz.fsf@keller.adm.naquadah.org> <87tykwpjfl.fsf@keller.adm.naquadah.org> <87r5g0mkuk.fsf@uwo.ca> <87aamnq2ek.fsf@keller.adm.naquadah.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1286611915 12487 80.91.229.12 (9 Oct 2010 08:11:55 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 9 Oct 2010 08:11:55 +0000 (UTC) Cc: ding@gnus.org To: Dan Christensen Original-X-From: ding-owner+M21180@lists.math.uh.edu Sat Oct 09 10:11:54 2010 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1P4UWz-0007cw-Hp for ding-account@gmane.org; Sat, 09 Oct 2010 10:11:49 +0200 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 1P4UWO-0002ZX-1c; Sat, 09 Oct 2010 03:11:12 -0500 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1P4UWL-0002ZB-SM for ding@lists.math.uh.edu; Sat, 09 Oct 2010 03:11:09 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtp (Exim 4.72) (envelope-from ) id 1P4UWJ-0005sv-Fs for ding@lists.math.uh.edu; Sat, 09 Oct 2010 03:11:09 -0500 Original-Received: from md5i.com ([75.151.244.229] helo=maru.md5i.com) by quimby.gnus.org with esmtp (Exim 3.36 #1 (Debian)) id 1P4UWI-0002bA-00 for ; Sat, 09 Oct 2010 10:11:06 +0200 Original-Received: from md5i by maru.md5i.com with local (Exim 4.72) (envelope-from ) id 1P4UVm-00032K-5H; Sat, 09 Oct 2010 04:10:34 -0400 In-Reply-To: <87aamnq2ek.fsf@keller.adm.naquadah.org> (Julien Danjou's message of "Sat, 09 Oct 2010 08:57:23 +0200") User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux) X-Spam-Score: -1.9 (-) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:72808 Archived-At: Julien Danjou writes: > On Fri, Oct 08 2010, Dan Christensen wrote: > >> I'm no expert, but my understanding is that in normal operation, >> UIDVALIDITY never changes, even when messages arrive, are deleted, or >> flags change. So it can't help solve the problem at hand. > > That's totally the opposite. A UIDVALIDITY number design a mailbox in a > state. If any change occurs, the UIDVALIDITY number changes. That's how > you know you need to do a FETCH 1:* to resynchronize your (cached) > version of the mailbox. > > Read section 2.3.1.1 of RFC3501. After re-reading that section, I think you are mistaken. UIDVALIDITY is guaranteed not to change as long as the messages in the mailbox have not changed their UIDs (or rather, as long as the mailbox maintains its identity). It does not change with the addition, or deletion, of messages to that mailbox. On the other hand, the UIDNEXT does change with the addition of new messages to the mailbox. It will not, however, change with the deletion of messages. The triple of mailbox name, UIDVALIDITY, and message UID will always refer to the same message no matter what, as long as that message still exists. "First, the next unique identifier value MUST NOT change unless new messages are added to the mailbox; and second, the next unique identifier value MUST change whenever new messages are added to the mailbox, even if those new messages are subsequently expunged." In the above extract, the "next unique identifier value" refers to UIDNEXT, not UIDVALIDITY. -- Michael Welsh Duggan (md5i@md5i.com)