[Dovecot] Custom flags in v1.0.15
Hello all,
I'm having problems with setting custom flags on a dovecot imap setup, with mbox mail store. I was running v1.0rc15 on a Debian Etch box, upgraded recently to v1.0.15, but nothing changed.
The problem : I read my mail using IMAP. In Thunderbird (various versions, current one being v2.0.0.19), I can set various message flags (Important, Personal, Work, ... mapped to IMAP as $Label4,$ $Label3, $Label2, ...). I read my mail from several machines, but all changes made on the message flags from one machine won't appear on the others !? Still I've read that those flags are supported in Dovecot. Actually, I logged the IMAP traffic, and saw that Dovecot claims to "handle" them. For instance, I added a flag to a message : Thunderbird > 621 uid store 35150 +FLAGS ($label4) Dovecot > * 6716 FETCH (UID 35150 FLAGS (\Seen \Recent $Label4))
Now, if I close TB, so that changes are written to the mbox file, and if I open that file on a the server with any text editor, the 'X-Keywords' line doesn't appear !? And as a matter of a fact, if I read my mail from any other machine, the flag isn't set !
Anyone knows where the problem can be ? Do I need to upgrade to v1.1 ? Or are custom flags actually supported in v1.0 (which I believe is the case) ? I browsed through the internet and searched the archives of this mailing list but didn't find any clue ... Any help would be much appreciated Thank you very much in advance
Pascal Mouret-- Pascal Mouret Responsable du Service Informatique Polytech' Marseille, Université de Provence 60, rue Joliot-Curie / 13453 Marseille cedex 13 Mel : pascal.mouret@polytech.univ-mrs.fr Tel : 04 91 11 38 04 / Fax : 04 91 11 38 54
On Thu, 2009-02-26 at 13:03 +0100, Pascal Mouret wrote:
Thunderbird > 621 uid store 35150 +FLAGS ($label4) Dovecot > * 6716 FETCH (UID 35150 FLAGS (\Seen \Recent $Label4))
Now, if I close TB, so that changes are written to the mbox file, and if I open that file on a the server with any text editor, the 'X-Keywords' line doesn't appear !? And as a matter of a fact, if I read my mail from any other machine, the flag isn't set !
That's a bit weird, but looks like I can reproduce it. Actually it doesn't look like any flags get written to the mbox file..
Anyone knows where the problem can be ? Do I need to upgrade to v1.1 ? Or are custom flags actually supported in v1.0 (which I believe is the case) ?
See if setting mbox_lazy_writes=no helps.
Hi Timo,
Thank you very much for the reply.
Timo Sirainen a écrit :
On Thu, 2009-02-26 at 13:03 +0100, Pascal Mouret wrote:
Thunderbird > 621 uid store 35150 +FLAGS ($label4) Dovecot > * 6716 FETCH (UID 35150 FLAGS (\Seen \Recent $Label4))
Now, if I close TB, so that changes are written to the mbox file, and if I open that file on a the server with any text editor, the 'X-Keywords' line doesn't appear !? And as a matter of a fact, if I read my mail from any other machine, the flag isn't set !
That's a bit weird, but looks like I can reproduce it. Actually it doesn't look like any flags get written to the mbox file..
Anyone knows where the problem can be ? Do I need to upgrade to v1.1 ? Or are custom flags actually supported in v1.0 (which I believe is the case) ?
See if setting mbox_lazy_writes=no helps.
That's it !!! I changed the line and it did the trick !! (To be more accurate, on my debian box, I had then to issue a /etc/init.d/dovecot restart. A simple /etc/init.d/dovecot force-reload was not enough) Thank you very much So it may be a problem when the flags are copied from the index file onto the main mbox file, right ? Is there a performance penalty of setting mbox_lazy_writes to no by the way ? I did a very basic test on a 500MB mbox (setting and unsetting flags on the second message of the mailbox, and grep'ing at the same time the file to see the changes : no noticeable delay. A ls -l even showed the file remained the same size, which explains it all !) Now, on a busy server, with a lot of flag changes (or rather a lot of flag additions), would that make a noticeable difference ? Anyway, thank you very much for your help, and thank you very much for the great job !
-- Pascal Mouret Responsable du Service Informatique Polytech' Marseille, Université de Provence 60, rue Joliot-Curie / 13453 Marseille cedex 13 Mel : pascal.mouret@polytech.univ-mrs.fr Tel : 04 91 11 38 04 / Fax : 04 91 11 38 54
On Thu, 2009-02-26 at 21:56 +0100, Pascal Mouret wrote:
See if setting mbox_lazy_writes=no helps.
That's it !!! I changed the line and it did the trick !! (To be more accurate, on my debian box, I had then to issue a /etc/init.d/dovecot restart. A simple /etc/init.d/dovecot force-reload was not enough) Thank you very much So it may be a problem when the flags are copied from the index file onto the main mbox file, right ?
Something like that. Strange that other people haven't complained about it being broken. Anyway v1.1 has fixed this already.
Is there a performance penalty of setting mbox_lazy_writes to no by the way ?
Yes.
Now, on a busy server, with a lot of flag changes (or rather a lot of flag additions), would that make a noticeable difference ?
No idea. It does make Dovecot do more work.
Timo Sirainen a écrit :
On Thu, 2009-02-26 at 21:56 +0100, Pascal Mouret wrote:
[...] Thank you very much So it may be a problem when the flags are copied from the index file onto the main mbox file, right ?
Something like that. Strange that other people haven't complained about it being broken. Anyway v1.1 has fixed this already.
Is there a performance penalty of setting mbox_lazy_writes to no by the way ?
Yes.
Is a fix available, or will a fix be available for v1.0 ? I mean, I've seen it's still v1.0.15 that is packaged in the brand new Debian stable (Lenny), so that may be useful for anyone using Debian (if there are actually more people who need the feature than people who raised the issue !!) Is that a hard work to do ? May I be of any help ?
Thank you very much again
Now, on a busy server, with a lot of flag changes (or rather a lot of flag additions), would that make a noticeable difference ?
No idea. It does make Dovecot do more work.
-- Pascal Mouret Responsable du Service Informatique Polytech' Marseille, Université de Provence 60, rue Joliot-Curie / 13453 Marseille cedex 13 Mel : pascal.mouret@polytech.univ-mrs.fr Tel : 04 91 11 38 04 / Fax : 04 91 11 38 54
On Fri, 2009-02-27 at 22:19 +0100, Pascal Mouret wrote:
Is a fix available, or will a fix be available for v1.0 ? I mean, I've seen it's still v1.0.15 that is packaged in the brand new Debian stable (Lenny), so that may be useful for anyone using Debian (if there are actually more people who need the feature than people who raised the issue !!) Is that a hard work to do ? May I be of any help ?
Even if I wrote the fix for v1.0, it wouldn't get added to Debian. And if you're not using the official Debian package, you might as well use v1.1.
Timo Sirainen a écrit :
On Fri, 2009-02-27 at 22:19 +0100, Pascal Mouret wrote:
Is a fix available, or will a fix be available for v1.0 ? I mean, I've seen it's still v1.0.15 that is packaged in the brand new Debian stable (Lenny), so that may be useful for anyone using Debian (if there are actually more people who need the feature than people who raised the issue !!) Is that a hard work to do ? May I be of any help ?
Even if I wrote the fix for v1.0, it wouldn't get added to Debian. And if you're not using the official Debian package, you might as well use v1.1.
I'm using the official package ! v1.0.15 is the official Debian Lenny stable package, and I'm using the Etch backport version of this package (cf http://packages.debian.org/search?suite=etch-backports&searchon=names&keywor...). So, I think a fix would be added (but I'm no Debian guru). I had a look at v1.1 : it only appears in Lenny unstable (v1.1.11), so using it in a Debian way means upgrading to Lenny and using unstable which is not recommended for production servers. But I'll have a closer look at it then Thank you very much
-- Pascal Mouret Responsable du Service Informatique Polytech' Marseille, Université de Provence 60, rue Joliot-Curie / 13453 Marseille cedex 13 Mel : pascal.mouret@polytech.univ-mrs.fr Tel : 04 91 11 38 04 / Fax : 04 91 11 38 54
participants (2)
-
Pascal Mouret
-
Timo Sirainen