I use this appender

<appender name="test" class="ch.qos.logback.core.rolling.RollingFileAppender">

    <prudent>true</prudent>

    <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">

        <fileNamePattern>./logs/free-%d{yyyy-MM-dd}.log</fileNamePattern>

        <cleanHistoryOnStart>true</cleanHistoryOnStart>

        <maxHistory>30</maxHistory>

        <totalSizeCap>70MB</totalSizeCap>

    </rollingPolicy>

    <encoder>

        <pattern>%d{yyyy-MM-dd HH:mm:ss} [%thread] (%level) %C(%F:%L) %n%msg%n</pattern>

    </encoder>

</appender>

then I write a test java code

public static void main(String[] args) {
     Logger logger = LoggerFactory.getLogger("test");
     for (int i = 0; i < 1000000; i++) {
         logger.info(UUID.randomUUID().toString());
     }
}

I run the program first time,It give me a logger file 114MB,it is very sad because the size is great than 70MB as conf file.

in the https://logback.qos.ch/manual/appenders.html you say the "total size cap" restriction applied second.

so I delete some log to make the log file size 12MB, and I rename the file name as it is created yesteday, then I run the java program again, when total size great than 70MB, the old log file is not delete, and the result is in Attachment pic1.PNG.

 

I‘d like discuss the requrement of TimeBasedRollingPolicy, I use it to split log by day, at the same time prevent the total log file great than the disk size or the server will wrong, so I need logback to hold all files which macthes fileNamePattern within disk size.

now I just use SizeAndTimeBasedRollingPolicy, but I dislike the %i.

So maybe this bug is more like a new feather, Hope logback do better.