[Dovecot] The CONTROL problem with fs quotas.
tss at iki.fi
Sun May 4 17:22:23 EEST 2008
On Fri, 2008-04-11 at 10:56 +0900, Jorgen Lundman wrote:
> We attempted to use CONTROL= with "%h", which would give us full
> directory hashing, however, we found that when it creates all the
> directories, it does so as the uid of the first user. So all following
> users (that hash in at least one part) will fail. Most likely because
> dovecot has already setuid()ed. Pre-creating the hashes is not feasible.
What do you mean by %h? That expands to home directory. %Hu then would
give a hash of the entire user name.
> => Dovecot would call "mkdir_parents" on "%h" _before_ setuid, but
> create the final directory after.
Probably won't work well at least everywhere, since the same problem
would be with deliver. Also mail_drop_priv_before_exec=yes is useful
sometimes and then this wouldn't be possible either.
> OR, Dovecot support (at least 2 level) directory hashing when specifying
This is already possible. You could use first two letters of the
username (CONTROL=%1u/%2.1u/%u = u/s/user) or first two letters of a MD5
sum of the user (CONTROL=%1u/%2.1u/%u). Precreating the directories for
at least the MD5 sum should be easy.
> OR, The ability to disable dovecot-uidlist (in memory is fine). (Setting
> INDEX=memory does not work for CONTROL=).
For POP3 with pop3_uidl_format=%f this would be a possibility, but for
IMAP it would cause UIDVALIDITY to change for every login and cause IMAP
clients to re-download all messages all the time.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://dovecot.org/pipermail/dovecot/attachments/20080504/378d936f/attachment.bin
More information about the dovecot