dovecot-1.0.10 on Solaris 10 x86, with NFS.

We currently have the problem that when customers go over their disk quota, the dovecot-uidlist file stops them from logging in.

In the interest of solving it, we considered moving the CONTROL file to a different file system. But:

1:

Using CONTROL= with "%u" will quite quickly run into the problem that the directory will fill up, and hit the maximum (around 32k) or so. We have 170k users so far, and more are being imported. You could cull some from crontab or similar, but is generally a poor way to solve a problem.

2:

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.

3:

Using 2, we could change umask to "0000" and hence it does not matter than all directory hash node are owned by a user's id, but this unfortunately includes all other directories, and having all directories at 777 is not an option.

Now, naturally, I can easily patch dovecot to call mkdir_parents with 0777 only for CONTROL. But I would rather not have local patches, meaning upgrades will be difficult. It would be preferable if:

=> Dovecot would call "mkdir_parents" on "%h" _before_ setuid, but create the final directory after.

OR, Dovecot support (at least 2 level) directory hashing when specifying CONTROL=%1/%2/%u

OR, The ability to disable dovecot-uidlist (in memory is fine). (Setting INDEX=memory does not work for CONTROL=).

Are there other solutions out there?

-- Jorgen Lundman | lundman@lundman.net Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work) Shibuya-ku, Tokyo | +81 (0)90-5578-8500 (cell) Japan | +81 (0)3 -3375-1767 (home)