Rick Romero wrote:
Ok, I have an odd problem. I tried both vpopmail 5.4.17 and 5.4.25. This is functioning on multiple FreeBSD machines, but failing on OpenSolaris. I've removed my maildirsize file multiple times. If I look at my account with an 8gb quota, and 923Mb of data (du -h) with vuserinfo, it reports 100% full.

/usr/local/vpopmail/bin/vuserinfo r...@havokmon.com
name:   rick
dir:       /usr/home/vpopmail/domains/havokmon.com/rick
quota:     8000000000
usage:     100%
:/usr/home/vpopmail/domains/havokmon.com/rick/Maildir# cat maildirsize
8000000000S
848908105 29941

So that's obviously wrong.   Now, if I check my wife's account it's fine:
:/usr/home/vpopmail/domains/havokmon.com/rick/Maildir# /usr/local/vpopmail/bin/vuserinfo she...@havokmon.com
name:   shelby
dir:       /usr/home/vpopmail/domains/havokmon.com/shelby
quota:     200000000
usage:     49%
cat  /usr/home/vpopmail/domains/havokmon.com/shelby/Maildir/maildirsize
200000000S
98759830 1339

If I reduce my quota from 8GB to 900Mb, I get:
quota:     900000000S
usage:     94%

I've played with my quota a bit, and somewhere around 2.2GB (2200000000) is where the math starts to fail.

So obviously something is not working right on OpenSolaris.
This works fine on FreeBSD machines, I'm building a new OpenSolaris server and am using the same MySQL backend, but a copy of the mailbox data.
#uname -a
SunOS sysvolOne 5.11 snv_101b i86pc i386 i86pc Solaris

It seems to be failing in maildirquota.c in qcalc:

               while (*quota >= '0' && *quota <= '9')
                       i=i*10 + (*quota++ - '0');
               switch (*quota) {
               default:
                       if (i < s)
                       {
                               *percentage=105;
                               return (-1);
                       }

When I set percentage to 105, that's what my output now says instead of 100. If I multiple i by 100 instead of 10. It says I have 84% used. So for some reason it seems 932M of 8Gb is calculating to 840%.

I assume it' some kind of compiler issue, but I don't know where to look.

Rick



i would guess it fails at 2147483648 and off_t ends up being signed 32bit, so it overflows.

i have no idea why that would happen, or should it happen always with 32 bit kernel.

++jukka

!DSPAM:49459e7032311621919728!

Reply via email to