Subject: Re: [lemonade] QRESYNC CLOSE race condition

From: Timo Sirainen <[email-masked]>
Date: Wed, 11 Jun 2008 05:42:18 +0300

On Sat, 2008-03-15 at 16:39 +0000, Alexey Melnikov wrote:
> Timo Sirainen wrote:
> 
> >If CLOSE expunges messages it sends the new HIGHESTMODSEQ in the tagged
> >reply. I guess the intent is that client could cache it and avoid
> >resyncing the expunge later. But what if two clients do changes:
> >
> >C1: 1 store 1 +flags.silent \deleted
> >S1: * 1 FETCH (modseq 1)
> >S1: 1 OK
> >
> >C2: 2 store 2 +flags.silent \deleted
> >S2: * 2 FETCH (modseq 2)
> >S2: 2 OK
> >C2: 3 expunge
> >S2: * VANISHED 2
> >S2: 3 OK [HIGHESTMODSEQ 3]
> >C2: 4 store 3 flags.silent \seen
> >S2: * 3 FETCH (modseq 4)
> >S2: 4 OK
> >
> >C1: 5 close
> >S1: 5 OK [HIGHESTMODSEQ 5]
> >
> >Client 1 now missed that UID 2 was just expunged and 3 had its flag
> >changed. To avoid this the server would have to send instead:
> >
> >C1: 5 close
> >S1: * VANISHED 2
> >S1: * 3 FETCH (FLAGS (\Seen) modseq 4)
> >S1: 5 OK [HIGHESTMODSEQ 5]
> >
> >Or did I miss something?
> >  
> >
> Your proposal seems correct. QRESYNCbis should include your example.

I'm beginning to think that CLOSE should always send VANISHED reply,
because the client can't reliably figure out what was expunged. For
example:

C1: 2 STORE 1 +FLAGS.SILENT \Deleted
S1: * 1 FETCH (MODSEQ 1)
S1: 2 OK

C2: 1 STORE 2 +FLAGS.SILENT \Deleted
S1: * 2 FETCH (MODSEQ 2)
S2: 1 OK

C1: 3 CLOSE
S1: 3 [HIGHESTMODSEQ 3]

The client probably thought that only message 1 was expunged, so it
doesn't register the second expunge. And it probably never will if it
uses QRESYNC to find out only about new expunges.

And even worse example would be if the second client had also removed
the \Deleted flag from message 1. Then the first client would have
registered wrong message to be expunged.
_______________________________________________
lemonade mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade