Ok. So it all narrowed down to qmail-local, I think.

So, the qmail-local maildir++ patch doesn't work on NFS (or just doesn't work, 
period) is a possibility.  So I switched back to my original qmail-local 
binary, and modified my /var/qmail/rc script to pipe to deliverquota ./Maildir 
as the maildrop/maildirquota documentation suggests.

I also seen something in the changelog about the 12 byte padding in 
maildirsize files to avoid nfs appending issues?  I believe the vuserinfo 
program from vpopmail, and possibly other maildir++ related code doesn't do 
this. Is this bad?

Also, I have all my virtual users managed by vpopmail from a mysql databse. 
maildropmysql.conf seems very powerful from a first glance, but I have one 

Vpopmail's default mysql table structure has two seperate fields, pw_name and 

and from maildropmysql.conf
# UID_FIELD - MySQL attribute which contains the users name (w or w/o domain)
uid_field               uid

Should there be an optional seperate domain field if uid_field only contains 
the username and not the full email?

I guess for now as a workaround I can create a new column call it 'email' for 
example and on mysql do:
UPDATE vpopmail SET full_name = CONCAT(pw_name, '@', pw_domain);

and set uid_field in maildropmysql.conf to 'email'

Would that be fine?

Also, regarding the uidnumber_field and gidnumber_field, are they required? 
Could maildrop automatically detect who the maildirs are owned by 
(vpopmail:vchkpw) and write new mail with the correct permissions.

I have used the 'to $VHOME/Maildir' from mailfilter called by maildrop 
from .qmail-default and it I didn't have to give it any special uid/gid other 
than compiling maildrop with uid root.

Quoting Sam Varshavchik <[EMAIL PROTECTED]>:

> Well, somehow messages that are added to the maildir are not added to the 
> quota, so when the messages are removed, the subtracted quota becomes 
> negative.
> I don't have an immediate idea why.  Although Maildir++ certainly trades in 
> some known race conditions in favor of lock-free operation, race condition 
> that would lead to such a situations should be very rare.  Perhaps NFS 
> exaggerates the conditions that lead to a race condition.
> But that's pure speculation.  What's needed is a reproducible way to create 
> this scenario.
> One potential workaround you can explore is to forcibly recompute the quota 
> if the apparent quota is negative.
> Try hacking the quota code to call maildir_quota_recalculate(), just once,
> if the apparent quota is negative, then try again.

Tim Hasson

Reply via email to