FileHandler log rotation can silently lose logs due to unhandled rename and file-open failures when log file is momentarily held by other processes.

java.util.logging.FileHandler performs log rotation by renaming log_0 to log_1, log_1 to log_2, ..., and finally re-opening log_0 for fresh logging.

When another process (e.g., log tailer/forwarder) holds log_0 briefly for reading (even a few milliseconds), two critical issues arise:

Bug 1: Silent rename failure leads to data loss

During rotation, log_i+1 is deleted and log_i is renamed to log_i+1.

The File.renameTo() call can fail if the file is momentarily held. This failure is not checked or reported.

Consequence: the current file (log_0) fails to rename to log_1, but log_1 is already deleted, resulting in total loss of that log generation.

Bug 2: Logging silently disabled after rotation

After rotation, FileHandler reopens log_0 for writing.

If the file is held by another process (with shared read access), open may fail, leaving FileHandler.writer as null.

Consequence: future log messages are accepted by the logger but silently dropped — no logging occurs until application restart.

Impact:

Silent log loss during rotation (Bug 1).

Logging completely stops with no error indication (Bug 2).

Steps to reproduce :

1. Run LogFileHolder.java in one terminal (which will lock log_0.log)
2. Run LogRotationTest.java in another terminal which will create the log files and add messages.

After the test is done we can clearly see there is a loss of few messages and also log files.

This issue is reproducible only on Windows OS.