Le 06/09/2011 19:48, Julien Coloos a écrit :
Le 06/09/2011 10:23, Greg Banks a écrit :
So I think we'll need another round, sorry :( Given that the
annotations quota is broken and I'll be reimplementing it anyway, you
may as well ignore QUOTA_ANNOTSTORAGE in all commits, and leave out the
function annotatemore_computequota() for now. We'll use something very
much like it for reconstruct later. I'm hoping to be able to pull your
next round of changes into my annotate branch before I reimplement the
annotation quota in the next few days.
If the new code is capable of returning actual resource usages upon
getquota (I think Bron wanted it that way), then I guess I can drop
some more of the functions I added (annotatemore_computequota, but
also mboxlist_updatequota and associated code including the
quota.sets[]; then maybe I could also change the code as proposed
earlier and prevent writing of resource limit in quota entry if it is
QUOTA_UNLIMITED). Will look at it tomorrow.
When I said 'actual', I meant based on the upcoming mailbox index field.
But wait, I got a bit confused with the last point about playing along
with quota.sets[]. If what you discussed with Bron is that, in the end,
usage (re)computing will only be done with the quota utility (no more
automatic computing upon setquota, neither for getquota), then after
upgrading people shall call 'quota -f' once and for all and quota.sets[]
must disappear - and all resources must be written in the quota entry -,
otherwise users would need to call 'quota -f' on a given quotaroot each
time they set a new quota resource limit to a mailbox.
Regards
Julien
