My previous thread showed me being successfully guided to a solution to rollover problems, by removing the File element of the rolling policy to avoid renaming issues. These problems surfaced in my instance due the following operational environment: 1) A GUI application running under Windows, not a server-side application. 2) Application is launched from time to time by different users. This leads to file-ownership issues preventing rename operation. Similar problems occur in the delete scenario based on the <maxHistory> element. But in this case, there is no workaround for deletion Also I wonder about this: TimeBasedArchiveRemover.cleanByPeriodOffset() calls java.io.File.delete(). File.delete() returns a boolean which is not checked in cleanByPeriodOffset(). It also throws a SecurityException (a RuntimeException) which isn't checked for. I'm not sure where this would be caught but I'm guessing it isn't the case here or we would have more catastrophic failures, so I suppose it's just returning false. Should logback do something about this? It's not clear because it's not clear what it could do. There is no alternative as in the case of renaming. Is there any solution available other than setting the directory so that every user has full rights to it? Mere write access is not enough in the Windows permissions scheme.