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 problem: Vpopmail's default mysql table structure has two seperate fields, pw_name and pw_domain 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. > > > Respectfully, Tim Hasson
