repository size

[John Glorioso <jg...@zitego.com>]

I have scoured the mailing archives and could not find any information 
on checking total repository size. I seem to recall someone asking about 
this, but I cannot find anything. What I would like to do is to create a 
matcher that checks the local user's repository to see the amount of 
space consumed and then determine whether to bounce the message or not 
if they have reached a variable limit.

Using a database repository, it is easy enough to select a sum of the 
length of the message_body column to get a close estimate, however I 
have converted to a dbfile repository and have concerns with how the 
mail file names are produced. They appear in the form:

4D61696C313037373230383830373132332D33.Repository.FileStreamStore

I naturally assumed the first part to be hex encoded, so I decoded that 
and found something more useful:

Mail1077208807123-3.Repository.FileStreamStore

Yay, a message_name! So, given that discovery is it "okay" to select the 
message_names for a repository, encode them, list the files from the 
file system after appending ".Repository.FileStreamStore" to each, and 
sum up the file sizes?

Is this a total hack or what? Is there a better way? I realize this is a 
performance hit. I could keep a running tab and update it after 
deliveries and deletes or something, but that is for later 
determination. Am I missing something simple or is this the best 
approach? Is it reliable to use this methodology or will I be screwing 
myself when later versions of James/Avalon come out?

Any comments are welcome (both positive and negative).


---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org

RE: repository size

["Noel J. Bergman" <no...@devtech.com>]

> I would like to do is to create a matcher that checks the
> local user's repository to see the amount of space
> consumed and then determine whether to bounce the message
> or not if they have reached a variable limit.

A variable limit is not currently implemented, but the
RecipientIsOverFixedQuota already implements the rest of what you want, and
the AbstractStorageQuota matcher provides the hooks if you want to implement
your own variable limit.

	--- Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org