On 06/03/2011 14:51, Stephen Usher wrote:
Actually it doesn't matter what the second client is (it can be another copy of TB3), the important thing is that TB3 doesn't notice the change underneath it. (The programmers seem to assume that it will have exclusive access to the mailbox from what I can see.) The real mailbox does change correctly, TB3's idea of what the mailbox holds does not and it fails to check its consistency with respect to the server.
Obviously there's a difference in behaviour for some reason when TB3 interacts with Cyrus IMAP as it seems not to have a problem with that IMAP server. It's almost as if TB3 expects to be informed when there has been a deletion. (TB3 will notice other status changes such as a message being read etc.)
I may just be having the same issue as you and it's been persistent for a while. I believe that it's possibly a bug related to IDLE in Dovecot (unproven and unsupported claim...)
Do you also get the same effect with read and unread marks?
We have three users here, all logging in from different local machines, which then go through a NAT (so to Dovecot they look the same IP), and all three machines log into the same account with the same credentials (ie shared inbox). We observe that generally the inbox view looks the same on all machines and I haven't noticed any deletes not syncing across instantly, but definitely there exists a set of circumstances where the read/unread marks are not synced correctly. I haven't nailed down the specifics but I believe it might occur when one TB client isn't focused on the shared inbox (background IDLE connection) and it might occur only after some mins have passed in that state (nat timeout?) and it might not occur if CONDSTORE is disabled on TB3...
Do you have a common NAT in your situation? Could there be a NAT timeout/IDLE permutation causing the effect you see?
Note that I can fix the sync issue by simply clicking back into the shared inbox, toggling the state a few times and we are back in again?
My best hunch is that there is some shared code in Dovecot to send IDLE updates every so often and it's hashed on username and IP (I think?), so if we have two users behind nat, one using the connection regularly and the other idle, I wonder if the nat is allowed to timeout on the idle machine? Definitely feels like CONDSTOR is part of the problem, but this would fit because each side of the link would disagree on last update?
Just an idea..
Ed W