Looks like there was a bug in here:
http://hg.dovecot.org/dovecot-2.2/rev/98195220a0f7
On 8.11.2012, at 0.08, Michael M Slusarz wrote:
> Quoting Timo Sirainen :
>
>> On 6.11.2012, at 3.49, Michael J Rubinsky wrote:
>>
>> These defines in mail-transaction-log-private.h anyway can be changed to
Quoting Timo Sirainen :
On 8.11.2012, at 0.34, Michael M Slusarz wrote:
Quoting Michael M Slusarz :
I see your point, but the problem is that is not intuitive when
reading the RFC. One part of the RFC defines the behavior of
VANISHED (EARLIER) as only returning changes since the
mod-se
Quoting Timo Sirainen :
On 8.11.2012, at 0.08, Michael M Slusarz wrote:
I'm not sure changing the defaults is a good idea. But if someone
does want to use a particular dovecot server as the backend for
activesync clients, for example, it would probably make sense to
allow these values to
On 8.11.2012, at 0.34, Michael M Slusarz wrote:
> Quoting Michael M Slusarz :
>
>> I see your point, but the problem is that is not intuitive when reading the
>> RFC. One part of the RFC defines the behavior of VANISHED (EARLIER) as only
>> returning changes since the mod-sequence given. And
Quoting Michael M Slusarz :
I see your point, but the problem is that is not intuitive when
reading the RFC. One part of the RFC defines the behavior of
VANISHED (EARLIER) as only returning changes since the mod-sequence
given. And you are correct that another part of the RFC says that,
On 8.11.2012, at 0.08, Michael M Slusarz wrote:
>> These defines in mail-transaction-log-private.h anyway can be changed to
>> make it much less likely to see your problem:
>>
>> /* Rotate when log is older than ROTATE_TIME and larger than MIN_SIZE */
>> #define MAIL_TRANSACTION_LOG_ROTATE_MIN_S
Quoting Timo Sirainen :
On 6.11.2012, at 3.49, Michael J Rubinsky wrote:
That would require infinitely storing the modseq of when each message
was expunged. Not very nice. Also the RFC talks a lot about this
situation. The SELECT command has two optional parameters to optimize
it.
The RFC *d
Quoting Timo Sirainen :
On 6.11.2012, at 3.49, Michael J Rubinsky wrote:
These defines in mail-transaction-log-private.h anyway can be
changed to make it much less likely to see your problem:
/* Rotate when log is older than ROTATE_TIME and larger than MIN_SIZE */
#define MAIL_TRANSACTION_L
On 6.11.2012, at 14.17, Timo Sirainen wrote:
> It would be possible to keep a separate expunge log which could remember the
> expunges longer. But that would be yet another different index file for
> Dovecot, which annoyingly complicates everything. And currently since it
> sounds like the only
Quoting Timo Sirainen :
On 6.11.2012, at 3.49, Michael J Rubinsky wrote:
That would require infinitely storing the modseq of when each message
was expunged. Not very nice. Also the RFC talks a lot about this
situation. The SELECT command has two optional parameters to optimize
it.
The RFC *
Quoting Robert Schetterer :
Am 06.11.2012 13:17, schrieb Timo Sirainen:
the only problem is activesync implementation using it
Hi, Michael,
as i am going to implement horde 5 active sync server in near Future
with dovecot , i followed this in high interest
I know horde active sync server is
Am 06.11.2012 13:17, schrieb Timo Sirainen:
> the only problem is activesync implementation using it
Hi, Michael,
as i am going to implement horde 5 active sync server in near Future
with dovecot , i followed this in high interest
I know horde active sync server is different to z-push
so sorry my
On 6.11.2012, at 3.49, Michael J Rubinsky wrote:
>> That would require infinitely storing the modseq of when each message
>> was expunged. Not very nice. Also the RFC talks a lot about this
>> situation. The SELECT command has two optional parameters to optimize
>> it.
>
> The RFC *does* indicate
Quoting Timo Sirainen :
On Mon, 2012-11-05 at 12:43 -0700, Michael M Slusarz wrote:
My argument is much simpler: it is blatantly breaking the RFC. From
RFC 5162 [3.2]:
The VANISHED UID FETCH modifier instructs the server to report those
messages from the UID set parameter that have b
On Mon, 2012-11-05 at 12:43 -0700, Michael M Slusarz wrote:
> My argument is much simpler: it is blatantly breaking the RFC. From
> RFC 5162 [3.2]:
>
> The VANISHED UID FETCH modifier instructs the server to report those
> messages from the UID set parameter that have been expunged and
Quoting Michael J Rubinsky :
I don't think they become incorrect, just that there are more of
them than really necessary? Yes, there's a tipping point. It's
when the modseq no longer exists in the dovecot.index.log* files,
which get rotated once in a while. This shouldn't happen very
ofte
Quoting Timo Sirainen :
On 5.11.2012, at 20.37, Michael J Rubinsky wrote:
On 5.11.2012, at 18.13, Michael J Rubinsky wrote:
I've been seeing the following wonky behavior with Dovecot.
Currently this is with Dovecot 2.0.19, but I was also seeing it
in earlier versions as well, including v
On 5.11.2012, at 20.37, Michael J Rubinsky wrote:
>> On 5.11.2012, at 18.13, Michael J Rubinsky wrote:
>>
>>> I've been seeing the following wonky behavior with Dovecot. Currently this
>>> is with Dovecot 2.0.19, but I was also seeing it in earlier versions as
>>> well, including versions from
Quoting Timo Sirainen :
On 5.11.2012, at 18.13, Michael J Rubinsky wrote:
I've been seeing the following wonky behavior with Dovecot.
Currently this is with Dovecot 2.0.19, but I was also seeing it in
earlier versions as well, including versions from the 1.x series.
Some background, thi
On 5.11.2012, at 18.13, Michael J Rubinsky wrote:
> I've been seeing the following wonky behavior with Dovecot. Currently this is
> with Dovecot 2.0.19, but I was also seeing it in earlier versions as well,
> including versions from the 1.x series. Some background, this is from
> Horde's Activ
Quoting Michael J Rubinsky :
Also, to verify it wasn't something screwy with my server, Michael
Slusarz provided me with this from his server:
There's definitely something wonky going on in the code. There's a
certain tipping point of modseqs where the values become incorrect.
For a ma
I've been seeing the following wonky behavior with Dovecot. Currently
this is with Dovecot 2.0.19, but I was also seeing it in earlier
versions as well, including versions from the 1.x series. Some
background, this is from Horde's ActiveSync library, when it is trying
to determine what UID
22 matches
Mail list logo
