On 09/27/10 23:26, Timo Sirainen wrote:
Thanks! But shouldn't "Avoid fsyncing subscriptions file when it doesn't change or if
mail_fsync=never." be "Avoid re-writing subscriptions file when it doesn't change and
fsyncing it if mail_fsync=never."?
I mean (I haven't read the code context) if you know that it does not change,
why write?
Ah, but I don't know :) The possibilities are:
a) Open a temp file and start writing new subscriptions to it. If we notice
that the subscription is there already, abort and delete the temp file. This is
how it works now.
I see, thanks.
That's because you have 4 autosubscribe entries. The current code doesn't allow
doing multiple subscription changes at once. But anyway, again, the problem
here is the autocreate plugin. I hated even adding it to included plugins, but
too many people just wanted it.
Sadly, I'm one of them. Currently during the provisioning it's not
guaranteed that a user will have a mailbox in the file system, so
autocreating it during pop logins is a bless. :)
But I will keep this in mind and will remove it as soon as I can.
(v2.1 way of handling it would be to have kind of virtual mailbox names that
are always listed, but actually physically created only when it's opened the
first time. That way you could also change them and if user has never actually
accessed a removed mailbox it would automatically also disappear.)
Sounds good.
