-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Timo,
On 2009-11-10 01:56, Timo Sirainen wrote:
On Mon, 2009-11-09 at 08:03 +0800, Patrick Nagel wrote:
This works for the first time after I edit the dovecot-virtual file and then access the virtual mailbox (all mails I expect to be shown in the todo mailbox are there) - but further accesses always show the same content, even though I removed the keyword from one of the mails (and I can confirm that the keyword has actually been removed by dovecot, since the filename doesn't contain the letter corresponding to the keyword anymore).
What about if you get client to issue EXPUNGE command? New messages should show up in mailbox automatically, but existing ones aren't removed unless EXPUNGE is given or mailbox is re-selected.
Hmm... I did some more testing. Since the Thunderbird 3.0 beta 4 I'm using right now seems to choose '$label4' as IMAP keyword for the 'To Do' tag, I added it to the search command, which is now
OR (OR KEYWORD $TODO KEYWORD todo) KEYWORD $label4
(Off topic: what a mess, why do they change the keywords all the time? I also see KMAILTODO, maybe from another version of KMail?)
Anyway, I did the following:
- Set the '$label4' keyword on two mails in my inbox via Thunderbird
- Checked the virtual.todo mailbox in Thunderbird - both mails were shown
- Unset the '$label4' keyword on one of the two mails in my inbox via Thunderbird
- Closed Thunderbird and opened it again (this should definitely re-select the virtual.todo inbox, right?)
- Checked the virtual.todo mailbox in Thunderbird - still both mails were shown
And then I had the following talk with my dovecot server:
$ /usr/sbin/dovecot --exec-mail imap
- PREAUTH [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH] Logged in as patrick 1 select virtual.todo
- FLAGS (\Answered \Flagged \Deleted \Seen \Draft $TODO KMAILFORWARDED KMAILTODO KMAILWATCHED KMAILIGNORED $FORWARDED $WATCHED $IGNORED $label4)
- OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft $TODO KMAILFORWARDED KMAILTODO KMAILWATCHED KMAILIGNORED $FORWARDED $WATCHED $IGNORED $label4 \*)] Flags permitted.
- 2 EXISTS
- 0 RECENT
- OK [UIDVALIDITY 1257723001] UIDs valid
- OK [UIDNEXT 4] Predicted next UID
- OK [HIGHESTMODSEQ 4] Highest 1 OK [READ-WRITE] Select completed. 1 fetch 1:2 flags
- 1 FETCH (FLAGS (\Seen))
- 2 FETCH (FLAGS (\Seen $label4)) 1 OK Fetch completed. 1 expunge 1 OK Expunge completed. 1 fetch 1:2 flags
- 1 FETCH (FLAGS (\Seen))
- 2 FETCH (FLAGS (\Seen $label4)) 1 OK Fetch completed. 1 select virtual.todo
- OK [CLOSED] Previous mailbox closed.
- FLAGS (\Answered \Flagged \Deleted \Seen \Draft $TODO KMAILFORWARDED KMAILTODO KMAILWATCHED KMAILIGNORED $FORWARDED $WATCHED $IGNORED $label4)
- OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft $TODO KMAILFORWARDED KMAILTODO KMAILWATCHED KMAILIGNORED $FORWARDED $WATCHED $IGNORED $label4 \*)] Flags permitted.
- 2 EXISTS
- 0 RECENT
- OK [UIDVALIDITY 1257723001] UIDs valid
- OK [UIDNEXT 4] Predicted next UID
- OK [HIGHESTMODSEQ 4] Highest 1 OK [READ-WRITE] Select completed. 1 fetch 1:2 flags
- 1 FETCH (FLAGS (\Seen))
- 2 FETCH (FLAGS (\Seen $label4)) 1 OK Fetch completed.
So it seems that neither EXPUNGE nor re-SELECT seems to have any "refreshing" effect.
Nikita Koshikov told me to "Try to add :INDEX=MEMORY to location setting".
After my tests above I tried that, and suddenly everything works as expected. It seems logical to have the index of a virtual folder in memory only, since it is generated dynamically anyway, and is outdated before it's even written to disk (at least without some configurable "virtual search result max age" parameter). So maybe the easiest solution is, to imply ':INDEX=MEMORY' when a namespace location is a virtual folder?
Patrick.
STAR Software (Shanghai) Co., Ltd. http://www.star-group.net/ Phone: +86 (21) 3462 7688 x 826 Fax: +86 (21) 3462 7779
PGP key: E883A005 https://stshacom1.star-china.net/keys/patrick_nagel.asc Fingerprint: E09A D65E 855F B334 E5C3 5386 EF23 20FC E883 A005 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkr5FGQACgkQ7yMg/OiDoAXY/wCgqJEw6yy3YH3//JBGDDBB+6Pj FCcAnREwazHZAEqqFyc7iGXIQiCz+mnP =u6rT -----END PGP SIGNATURE-----