--- J C Lawrence <[EMAIL PROTECTED]> wrote: > > Further to my previous email, I'm now looking to get some > > customisation of MHonArc done professionally to add a required > > feature. The work would involve adding an option to a resource file, > > whereby the amount of disk space that an archive occupied could be > > limited. > > This doesn't inherently need a modification to MHonArc. Just wrap your > call to MHonArc in a script which runs `du` against the target > directory, adds in the computed size of the current message and then > does The Right Thing.
But what exactly is "The Right Thing"? Various solutions exist to get the size of messages outside of mhonarc (attachments and a little twist, but is manageable). However, the trick is how to tell mhonarc to delete older messages until the total archive size is below max bytes size. I do not see an efficient solution to this that does not require hooking into mhonarc itself or performing your own bookkeeping of messages (duplicating some of what mhonarc does). As always, there is more than one way to solve the problem, it is just a matter of what is the best solution based on usage requirements. Processing outside of mhonarc itself is doable, but is less efficient. If mhonarc tracked byte sizes of converted messages (along with their attachments), it can easily auto-remove older messages, when needed, and do it during a single update operation. BTW, external-based processing would may need to deal synchronization issues. I.e. Some form of external locking is needed on the archive to avoid multiple processes from accessing the archive. Something like Procmail's lockfile could be used to manage this. --ewh
