I believe the root cause of this problem is that the SizeAndTimeFNATP appender doesn't take into account the number of instances of the log files it's archiving. I just had the following problem that illustrates this:

1. Log output total per day 450GB (yes it's huge!!)
2. Configuration set: maxHistory = 1, maxFileSize = 10MB
3. Filename: cts-dashboard-request.trace.%d {yyyy-MM-dd}

   .%i.log (one file per day)
   Result: Hard disk filled up with at 48GB of log file when I was expecting the logs to be limited to 2 files maximum of 10MB each.
   Analysis: There were 4500+ log files in the archive log directory!
   Root cause: The maxFiles will limit the number of files based on the file naming pattern, BUT not the number of instances within that file naming pattern. This means that if the log file rolls enough it will fill the hard disk while still adhering to its configuration.

The problems illustrated above are all instances of this same problem. The instance count is increasing while the filename (based on the pattern) is exactly the same. Since the file name didn't change, the "prune" logic isn't being triggered; hence "extra" log files are being left in the directory.

A potential solution would be to configure to not allow file instances (but then logging information would be lost), or limit the number of instances created like LOGBACK-253.