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.Though, it may be safe to check this with a configure test (since theActually, I lied here.
quotas are all stored as strings, not binary data).
We do store the used quota as binary data in the index header.
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.
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.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.
-- John A. Tamplin Unix System Administrator Emory University, School of Public Health +1 404/727-9931
