Hi Timo,
I'm just curious... is the Wiki up to date regarding the status of Shared Folder support for Dovecot?
Specifically, does Dovecot still have a problem with Read-only (for certain users) maildirs using Shared folders defined via namespaces?
I'm about ready to start testing a rollout, but wanted to find out what to expect with regard to Shared Folders - we use them extensively right now (Courier-imap), so it is important for us.
Having per-user read/unread flags will be a very nice bonus, but I don't see anything about support for those...
--
Best regards,
Charles Marcus I.T. Director Media Brokers International 678.514.6200 x224 678.514.6299 fax
On Tue, 2006-10-24 at 12:33 -0400, Charles Marcus wrote:
Hi Timo,
I'm just curious... is the Wiki up to date regarding the status of Shared Folder support for Dovecot?
Support for "Public folders" is doable, users sharing folders to each others is not supported.
BTW. I did think about this (and many other things) recently when driving several hours in a car and having nothing else to do. I guess I should write down those ideas before I forget about them completely again.
Specifically, does Dovecot still have a problem with Read-only (for certain users) maildirs using Shared folders defined via namespaces?
I think it should work.. At least I can't remember why it wouldn't work. If it does, please remove that text from the wiki :)
Having per-user read/unread flags will be a very nice bonus, but I don't see anything about support for those...
That works too, as long as you set the index file path to be different for each user, ie. something like:
location = maildir:/var/public/Maildir:INDEX=%h/.shared-indexes
I'm just curious... is the Wiki up to date regarding the status of Shared Folder support for Dovecot?
Support for "Public folders" is doable, users sharing folders to each others is not supported.
Good - while users being able to Share folders would be 'nice', it certainly isn't a requirement for us... :)
BTW. I did think about this (and many other things) recently when driving several hours in a car and having nothing else to do. I guess I should write down those ideas before I forget about them completely again.
Please do! I'm sure they are great ideas, seeing as how great dovecot is in general... :)
Specifically, does Dovecot still have a problem with Read-only (for certain users) maildirs using Shared folders defined via namespaces?
I think it should work.. At least I can't remember why it wouldn't work. If it does, please remove that text from the wiki :)
I'll certainly do so when I am able to confirm this... thanks!
Having per-user read/unread flags will be a very nice bonus, but I don't see anything about support for those...
That works too, as long as you set the index file path to be different for each user, ie. something like:
location = maildir:/var/public/Maildir:INDEX=%h/.shared-indexes
Perfect! Thanks Timo!
--
Best regards,
Charles
On October 24, 2006 7:47:52 PM +0300 Timo Sirainen tss@iki.fi wrote:
On Tue, 2006-10-24 at 12:33 -0400, Charles Marcus wrote:
Having per-user read/unread flags will be a very nice bonus, but I don't see anything about support for those...
That works too, as long as you set the index file path to be different for each user, ie. something like:
location = maildir:/var/public/Maildir:INDEX=%h/.shared-indexes
hmm, so in this case the indexes are critical information? whereas otherwise I thought they could be safely destroyed or removed if corrupted. eg, i just moved my mail server from 32-bit x86 to 64-bit sparc and had to destroy all indexes.
-frank
On Tue, 2006-10-24 at 12:31 -0700, Frank Cusack wrote:
On October 24, 2006 7:47:52 PM +0300 Timo Sirainen tss@iki.fi wrote:
On Tue, 2006-10-24 at 12:33 -0400, Charles Marcus wrote:
Having per-user read/unread flags will be a very nice bonus, but I don't see anything about support for those...
That works too, as long as you set the index file path to be different for each user, ie. something like:
location = maildir:/var/public/Maildir:INDEX=%h/.shared-indexes
hmm, so in this case the indexes are critical information?
Yes, the seen-flag state in them is critical information then.
I was thinking about making the index file code more resistant to simply giving up and rebuilding the index, so that it would try to preserve the flag state as long as possible. Actually I don't think it has happened to pretty much anyone with the current code. But still theoretically it could use a few more fixes. :) This is also useful for dbox if it's being run in "keep flags/keywords only in index files" mode (I guess this option could just as well be added for mbox/maildir if someone wants).
whereas otherwise I thought they could be safely destroyed or removed if corrupted. eg, i just moved my mail server from 32-bit x86 to 64-bit sparc and had to destroy all indexes.
Maybe I'll also some day write code that will automatically convert the endianess correctly. :) At least for the important fields (header, uid, flags, keywords) and drop all the rest.
On October 24, 2006 10:43:12 PM +0300 Timo Sirainen tss@iki.fi wrote:
Maybe I'll also some day write code that will automatically convert the endianess correctly. :) At least for the important fields (header, uid, flags, keywords) and drop all the rest.
Doesn't even have to be automatic. Utilites to dump and rebuild the indexes outside of dovecot would be useful.
-frank
On Tue, 2006-10-24 at 13:22 -0700, Frank Cusack wrote:
On October 24, 2006 10:43:12 PM +0300 Timo Sirainen tss@iki.fi wrote:
Maybe I'll also some day write code that will automatically convert the endianess correctly. :) At least for the important fields (header, uid, flags, keywords) and drop all the rest.
Doesn't even have to be automatic. Utilites to dump and rebuild the indexes outside of dovecot would be useful.
Dumping part is actually already done. Although it's useful only for debugging purposes:
http://dovecot.org/tools/idxview.c http://dovecot.org/tools/logview.c
Having per-user read/unread flags will be a very nice bonus, but I don't see anything about support for those...
That works too, as long as you set the index file path to be different for each user, ie. something like:
location = maildir:/var/public/Maildir:INDEX=%h/.shared-indexes
hmm, so in this case the indexes are critical information?
Yes, the seen-flag state in them is critical information then.
Hmmm... I've never had to rebuild the normal indexes on dovecot - when this happens, do all messages on the next login show as read?
I was thinking about making the index file code more resistant to simply giving up and rebuilding the index, so that it would try to preserve the flag state as long as possible. Actually I don't think it has happened to pretty much anyone with the current code. But still theoretically it could use a few more fixes. :) This is also useful for dbox if it's being run in "keep flags/keywords only in index files" mode (I guess this option could just as well be added for mbox/maildir if someone wants).
Probably a dumb question - how practical would it be for dovecot to keep a backup version of the index files, that it could roll back to (at least for the flags (\Seen, etc)?
--
Best regards,
Charles
On Tue, 2006-10-24 at 16:24 -0400, Charles Marcus wrote:
Having per-user read/unread flags will be a very nice bonus, but I don't see anything about support for those...
That works too, as long as you set the index file path to be different for each user, ie. something like:
location = maildir:/var/public/Maildir:INDEX=%h/.shared-indexes
hmm, so in this case the indexes are critical information?
Yes, the seen-flag state in them is critical information then.
Hmmm... I've never had to rebuild the normal indexes on dovecot - when this happens, do all messages on the next login show as read?
They show as whatever the seen flags were set in the master maildir. Most likely they'll show up as unread.
I was thinking about making the index file code more resistant to simply giving up and rebuilding the index, so that it would try to preserve the flag state as long as possible. Actually I don't think it has happened to pretty much anyone with the current code. But still theoretically it could use a few more fixes. :) This is also useful for dbox if it's being run in "keep flags/keywords only in index files" mode (I guess this option could just as well be added for mbox/maildir if someone wants).
Probably a dumb question - how practical would it be for dovecot to keep a backup version of the index files, that it could roll back to (at least for the flags (\Seen, etc)?
The index files are recreated by create a temp file and then rename()ing over every time when mails are being expunged. Before the rename() the old file could be link()ed to a backup file, so this could be done somewhat easily. Then if the index file is found to be corrupted, the backup file could be renamed to main index file.
I don't think it's worth the trouble though.
participants (3)
-
Charles Marcus
-
Frank Cusack
-
Timo Sirainen