BUG: Log clean up - configured # of days

[Scott MacDonald]

I've noticed that there seems to be some discrepancy (a bug perhaps) between the number of user, delivery, quarantine logs left and the configured # of days value that is set (30 days - delete logs older than).

For example, it is June 2nd and I have log files going back until May 2nd, which at first glance one might think yup - bang on! Oh, but wait ... May has 31 days and its June 2nd?? That means I currently have 32 days of log files. I would have expected the older than 30 days to take into account the present day in this calculation even though it is legitimately still logging new entries .. and thus we have 2 days more than the default configured older than 30 days.

[SH]

Thanks for reporting! For croned clean it uses find -mtime +30...

• +1 day are old logs which ignored timezone (ref #306) and updated file another day so timestamp is newer. good news is that it will fade away itself
• +1 day - "+30" means greater than AND find don't count fractions, so technicaly it will always clear logs which are >= 31days

Also it might happen that before cron is run and after midnight there will be another +1 day. It is funny one.

[SH]

fix #353 off by one find interval fix

→ <<cset a29d29721a15>>