On Tue, Aug 21, 2007 at 11:38:17AM -0500, John Goerzen wrote: > On Tue August 21 2007 10:02:58 am Daniel Jacobowitz wrote: > > > Could you avoid caching the UIDVALIDITY until the first time you've > > done something likely to stabilize it? Hmm, doesn't look easy. > > Possibly try SELECT and fall back to EXAMINE only if imapobj.readonly? > > Will this break \Recent somehow? > > I don't know. I don't use readonly folders myself, and they seem to be > implemented differently from server to server anyway. I'm hesitant to touch > that code too much.
I think it's the only sensible way things will work with existing Courier. > > It's compliant with the RFC and I can see some practical reasons for > > this; you have asked Courier to open the folder read-only, so there is > > nowhere that it can save the UIDVALIDITY value without writing to the > > folder. > > Down that path lies madness. > > Opening a folder read-only should refer to the ability of the client to > modify things in it, not to the ability of the server to present consistent > metadata. > > Consider this: On Monday, you connect to a Courier IMAP server and SELECT > folder foo. UIDs are set and a uidvalidity is established. You disconnect > and don't make any further connection attempts until Tuesday. On Tuesday, > you EXAMINE the folder. Courier returns the same UIDVALIDITY as on Monday, > but 50 new messages have arrived. If Courier interprets EXAMINE to > mean "don't open anything writable", how will Courier store the UIDs that > have been assigned to these messages, so that when you EXAMINE again on > Wednesday, you get the exact same UIDs for the same 50 new messages > messages? > > I would think that Courier would *have* to write to disk in that situation. Maybe it has to, but it doesn't. I can provoke an IMAP protocol violation by trying this. I would still be happy if offlineimap could avoid this newly discovered problem, so I think we should leave this bug assigned to offlineimap; I will open a new one for courier. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
