Bug 1274572 - [GSS](6.4.z) Log rotation fails on Windows if target already exists
Summary: [GSS](6.4.z) Log rotation fails on Windows if target already exists
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Logging
Version: 6.4.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: CR1
: EAP 6.4.10
Assignee: Panagiotis Sotiropoulos
QA Contact: Nikoleta Hlavickova
URL:
Whiteboard:
Depends On:
Blocks: 1278806 eap6410-payload
TreeView+ depends on / blocked
 
Reported: 2015-10-23 03:24 UTC by James Livingston
Modified: 2019-08-15 05:43 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: NIO File.moveTo() has implementation/OS-specific behaviour, and what JBoss LogManager relied upon was not portable. Consequence: Log file rotation fails on Windows if the target exists. Fix: Use NIO Files.move() with the replacing option instead. Result: Log files can be rotated correctly on Windows when the target file already exists.
Clone Of:
Environment:
Last Closed: 2017-01-17 12:58:19 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker LOGMGR-125 0 Major Resolved Log rotation fails on Windows if target already exists 2018-07-04 08:33:51 UTC

Description James Livingston 2015-10-23 03:24:18 UTC
The rotating file handlers use File.moveTo() which is noted in the JavaDoc as being highly implementation dependent. One example of this is that on Linux it will replace an existing target, but on Windows it will fail when doing that.

A consequence of this is that if the periodic rotating file handler re-uses a file name, e.g. with a suffix only containing the date and not month or year, it will throw an exception, and continue logging to the same file.

This can be fixed by using Files.move() with the option to replace the target file.

Comment 1 James Livingston 2015-10-23 03:35:51 UTC
Posted PR to backport to the jboss-logmanager 1.5 branch, https://github.com/jboss-logging/jboss-logmanager/pull/90. If accepted, this bug can be fixed by upgrading to the next release.

Comment 2 James Livingston 2015-10-23 03:37:52 UTC
A work-around for this bug is to use a file suffix with more data, such as the much more common yyyy-MM-dd.

Comment 3 James Perkins 2015-10-23 15:38:37 UTC
Since the 1.5 logmanager stream relies on Java 6 the 2.x branch fix won't work. We'll need to first delete the file, then rename it to replicate the move/replace.

Comment 4 Panagiotis Sotiropoulos 2015-10-30 10:42:41 UTC
PR sent : https://github.com/jboss-logging/jboss-logmanager/pull/91

Comment 7 Jiří Bílek 2016-08-09 11:29:24 UTC
Verified with EAP 6.4.10.CP.CR1

Comment 8 Petr Penicka 2017-01-17 12:58:19 UTC
Retroactively bulk-closing issues from released EAP 6.4 cummulative patches.


Note You need to log in before you can comment on or make changes to this bug.