search for: unchangedsinc

In a mailbox that has ACL restrictions on both DELETE and EXPUNGE (i.e. no 'e' or 't' rights), I see the following: 3 UID STORE 3173 (UNCHANGEDSINCE 353) +FLAGS \deleted 3 OK Store completed. (UID 3173 is not flagged \deleted) [...] 6 UID EXPUNGE 1:* 6 OK Expunge completed. (At least 1 UID is flagged \deleted in mailbox) Shouldn't these commands be returning "NO" instead of "OK"? RFC 3501 [6.4.6] for STORE:...

...a higher HIGHESTMODSEQ than what's used after CONDSTORE is enabled. This is because modseqs aren't tracked until client has told us that it wants them. So Dovecot doesn't waste time trying to figure out the correct HIGHESTMODSEQ.. Something probably should be done about this. - STORE (UNCHANGEDSINCE xx) doesn't work correctly. The full fix would require adding a new transaction log record type containing the modseq, but currently it doesn't even bother refreshing the mailbox state before checking what the modseqs are. The modseq numbers are calculated as: modseq = ((indexid + log_fi...

...(BODY[HEADER]) * 30 FETCH (UID 13608 FLAGS (\Seen \Recent impflag0) BODY[HEADER] {2529} ... As can be seen, impflag0 has been magically set somehow. Stranger still, dovecot won't let you unset the flag (this might have something to do with QRESYNC since, if I run this command without the UNCHANGEDSINCE parameter, it will unset the flag): 4 UID STORE 13608 (UNCHANGEDSINCE 82) -FLAGS (impflag0) 4 OK Store completed. FYI, I am using dovecot 1.2.1 on archlinux (they haven't upgraded the package to 1.2.2 yet, but I didn't see anything in the 1.2.2 release notes that leads me to believe...

RFC 5162 [3.1] states that a QRESYNC should return all changes in a SELECT/EXAMINE since the given modseq. In the following case, it looks like there is an off-by-1 error somewhere: C: A64 SELECT "TestMailboxTest" (QRESYNC (1224531494 6 1,3:5)) [MMS: MODSEQ given is 6] S: * OK [CLOSED] S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) S: * OK [PERMANENTFLAGS (\Answered \Flagged

...eird issue in a mailbox that has 26+ keywords. In one session, I do this: S: 2 SELECT "INBOX" (QRESYNC (1255685337 78608 [...uids...])) S: [...] S: * OK [HIGHESTMODSEQ 78608] Highest S: * OK [UIDVALIDITY 1255685337] UIDs valid S: 2 OK [READ-WRITE] Select completed. C: 3 UID STORE 48386 (UNCHANGEDSINCE 78608) +FLAGS AAAAAAAA S: * 8 FETCH (UID 48386 MODSEQ (78609) FLAGS (\Seen AAAAAAAA)) S: 3 OK Store completed. C: 4 LOGOUT S: * OK [CLOSED] Previous mailbox closed. S: * BYE LOGOUT received S: 4 OK Completed The next time I access that mailbox, I see this: C: 2 SELECT "INBOX" (QRESYNC...

...anges (that were already once applied). There could still be conflicting changes, but the result would be better for updates that had been delayed for a long time. Finding these flag changes and old flag values isn't simple though, so this won't be at least in initial implementation. STORE UNCHANGEDSINCE (CONDSTORE extension) is initially implemented by grabbing a master lock. If there are simultaneous STOREs in other servers, they'll temporarily have lower modseqs and different message flags. Eventually when the STOREs reach the master, they will be applied on top of the CONDSTORE modificatio...

I merged all the new features and latest v1.1 changes under one tree: http://hg.dovecot.org/dovecot-1.2/ The changeset order is kind of weird though. The timestamps jump all around. Wonder if there's a way to reorder them so that it looks more sane.. The status of the new features: 1. CONDSTORE extension is probably the largest change. It adds new "modification sequences" for

...it was just expunged. Changing message flags ---------------------- STORE: - Mailbox ID - UID range - Added flags/keywords - Removed flags/keywords - [Current modseq] (master sends) - [Highest modseq of the messages before this change] (non-master sends) - [flag: this is a CONDSTORE STORE UNCHANGEDSINCE] (non-master may send) [Reply: - UIDs where STORE was rejected to (if CONDSTORE flag was used) ] Stores also have to be sent via master server to avoid flag desynchronization. Master first checks if it has higher modseqs in the messages. Then it applies all the changes and forwards the changes t...

...ervers because it was just expunged. Changing message flags ---------------------- STORE: - IMAP UIDs - Added flags/keywords - Removed flags/keywords - [Current modseq] (master sends) - [Highest modseq of the messages before this change] (non-master sends) - [flag: this is a CONDSTORE STORE UNCHANGEDSINCE] (non-master may send) [Reply: - IMAP UIDs where STORE was rejected to (if CONDSTORE flag was used) ] Stores also have to be sent via master server to avoid flag desynchronization. Master first checks if it has higher modseqs in the messages. Then it applies all the changes and forwards the chan...

.../dovecot-virtualboxes/ Virtual mailboxes. Nothing changed since http://dovecot.org/list/dovecot/2008-March/029546.html 3. http://hg.dovecot.org/dovecot-condstore/ Implemented CONDSTORE, QRESYNC, ESEARCH, SEARCHRES and WITHIN extensions. The only known problem left is making CONDSTORE's STORE UNCHANGEDSINCE operation atomic, but it requires changing transaction log file format. Maybe I'll do it and just make v1.1 and v1.0 be able to read the format and just ignore the modseq in the record. Those code trees don't contain all the latest changes from v1.1 tree. So at some point I'll start m...