Bug 1274572

Summary:	[GSS](6.4.z) Log rotation fails on Windows if target already exists
Product:	[JBoss] JBoss Enterprise Application Platform 6	Reporter:	James Livingston <jlivings>
Component:	Logging	Assignee:	Panagiotis Sotiropoulos <psotirop>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Nikoleta Hlavickova <nziakova>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	6.4.0	CC:	andreas.lau, bbaranow, bmaxwell, brian.stansberry, istudens, jbilek, joallen, jperkins, psotirop
Target Milestone:	CR1
Target Release:	EAP 6.4.10
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
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.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-01-17 12:58:19 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1278806, 1339868

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.