quota warning problem - Is it a bug of cyrus imap?

[John Alton Tamplin]

Rob Siemborski wrote:

>>Though, it may be safe to check this with a configure test (since the
>>quotas are all stored as strings, not binary data).
>>    
>>
>Actually, I lied here.
>
>We do store the used quota as binary data in the index header.
>  
>
So the quota used for a particular mailbox (independent of the quota 
root it belongs to) is stored in cyrus.index as a 32-bit network 
byte-order integer, right?  It looks like that could be handled in an 
upwards-compatible way either by checking the start offset just like it 
is done for pop3_last_login, uidvalidity, flags, and pop3_new_uidl or by 
using a new minor number in the index file.  If the former approach is 
used, the high 32 bits would have to be stored at the end, while with a 
new minor version of the format it could be kept together.

Since the actual quota files are in ASCII, it is trivial to support 
upwards compatibility -- just include code capable of reading/writing 
64-bit numbers.

>But I suspect we could cheat and just write out the initial 4 bytes
>as zeros on platforms without long long (we'd have to upgrade the index
>files in any event).
>
>I strongly perefer something more generic than this though, splitting the
>build in this way may make quota problems hard to debug.
>
How about creating a new type, which can be long long on appropriate 
platforms or a struct { unsigned long hi, lo; } on ones without long 
long support, and a set of functions for reading, writing, and math on 
these types?  Those could be macros or inline functions for platforms 
with long long support and not lose much efficiency, while still 
supporting older/smaller platforms.

-- 
John A. Tamplin                               Unix System Administrator
Emory University, School of Public Health     +1 404/727-9931