hi On Sat, 15 Sep 2007, Sam Varshavchik wrote:
> Furthermore this is not going to be limited to deleting messages. A copy > operation to another folder will have the same effect, there's nothing > magical about the trash folder, in that respect. Well, the Trash folder is special in this case since other folders are normally "protected" by the mailbox quota, while Trash is not. So while TB can potentically do the same thing to other folders, it will stop as soon as quota is exceeded. Also, Trash is somewhat special in general, since it has a higher potential to have a large amount of messages dumped into it at once ;) > Also, the metric needs to > be more pliable. Copying 400 large, multimegabyte messages will also have > the same impact. Good point. I haven't seen it in my case, but it's easy to modify the patch to call do_msgset with the &do_copy_quota_calc callback, and account for the message size too, especially since I'm already calling imapscan. > side effects would be undesirable. Furthermore, it does quite a bit of work. > For these purposes, just counting the number of messages is sufficient, but > again, raw message counts may not be an ideal metric. I called it in read only mode (same way STATUS is handled) to minimize the impact and so I wouldn't have to worry about locking and other things imapscan is handling already. It can defintely be optimized. For me it wasn't really worth it, since I'm only doing it for the Trash folder. > Of course, there's nothing wrong with you employing a custom code patch for > your specific individual needs, but as it is, verbatim, I don't think it's > suitable to be included in generic code that everyone uses, and not just for > the reasons you say. I am not completely against doing something about this, > except that I don't feel comfortable with this specific solution. I'm going > to be taking a few days off soon, and I'll try to think about better > solution for this. I agree that a universal solution would be much better. I hope you can find one. thanks ! -- rgds, serge ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
