Bug 1274572 - [GSS](6.4.z) Log rotation fails on Windows if target already exists
[GSS](6.4.z) Log rotation fails on Windows if target already exists
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Logging (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: CR1
: EAP 6.4.10
Assigned To: Panagiotis Sotiropoulos
Nikoleta Ziakova
Depends On:
Blocks: 1278806 eap6410-payload
  Show dependency treegraph
Reported: 2015-10-22 23:24 EDT by James Livingston
Modified: 2017-01-17 07:58 EST (History)
9 users (show)

See Also:
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:
Last Closed: 2017-01-17 07:58:19 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker LOGMGR-125 Major Resolved Log rotation fails on Windows if target already exists 2018-07-04 04:33 EDT

  None (edit)
Description James Livingston 2015-10-22 23:24:18 EDT
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-22 23:35:51 EDT
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-22 23:37:52 EDT
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 11:38:37 EDT
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 06:42:41 EDT
PR sent : https://github.com/jboss-logging/jboss-logmanager/pull/91
Comment 7 Jiří Bílek 2016-08-09 07:29:24 EDT
Verified with EAP 6.4.10.CP.CR1
Comment 8 Petr Penicka 2017-01-17 07:58:19 EST
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.