I think you've misdiagnosed the problem.
As written, n is defined as a long when sscanf is called. It probably
isn't a grand idea to re-use the variable name, but it is a long. I'm
sure this problem would have cropped up earlier if not.
There were some changes to maildirquota.c for the 5.4.12 release
(IIRC), I'll have to go back and review them.
There's probably a problem elsewhere in the maildirquota code, where we
use an unsigned long instead of a long.
When you made the change, did the problem go away?
On Jan 24, 2006, at 11:48 AM, Jon Simola wrote:
Tracked down a bug that was causing our users to exceed their quota
without any mail in their boxes.
Deleted mail with entries in the maildirsize showing as
" -4804 -1"
are parsed incorrectly by the sscanf in maildirsize_read() in file
maildirquota.c at line 335:
sscanf(q, "%ld %d", &n, &c);
This ends up setting n to a large value (around 4294962492) which
makes the users' typical 25MB quota far over.
At the top of the function, n is declared as an int (line 285), and
midway through the function there is "long n=0;" at line 319 which
appears to have been intended to be used within the scope of the while
vpopmail 5.4.12 running on OpenBSD 3.8
--- maildirquota.c.orig Tue Jan 24 11:24:36 2006
+++ maildirquota.c Tue Jan 24 11:24:58 2006
@@ -283,5 +283,5 @@
- int n;
+ long n;