After a restart SizeAndTimeBasedFNATP uses incorrect sequence numbers for rollover files if compression is enabled ------------------------------------------------------------------------------------------------------------------ Key: LBCORE-161 URL: http://jira.qos.ch/browse/LBCORE-161 Project: logback-core Issue Type: Bug Components: Rolling Affects Versions: 0.9.24 Reporter: Frank Bos Assignee: Logback dev list Priority: Minor To reproduce this issue you can use a setup similar to the one used for LBCORE-131, but then use a filename pattern like "log.%d{yyyy-MM-dd}.%i.txt.gz" for the RollingPolicy. This works fine as long as you don't restart the application that is doing the logging. The following files are created: {noformat} log.2010-08-02.0.txt.gz log.2010-08-02.1.txt.gz log.2010-08-02.2.txt ( = active log file) {noformat} However, after a restart the following happens: {noformat} log.2010-08-02.0.txt.gz log.2010-08-02.1.txt.gz log.2010-08-02.1.txt (!!) log.2010-08-02.2.txt.gz log.2010-08-02.3.txt.gz log.2010-08-02.4.txt (the active log file) {noformat} So there are now two versions of the logfile with index 1: one zipped and one unzipped. They do not contain the same messages! Also the order of the messages in these logfiles is not what I expected. After the restart logback will first create the 'log.2010-08-02.1.txt' file and after that it will fill the existing 'log.2010-08-02.2.txt' file to the rollover size. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira