Due to filename "tunneling" on Windows, the creation date of a rotated logfile is not correct.
LogFile_WIN32.cpp contains this attempt at a work-around:
// There seems to be a strange "optimization" in the Windows NTFS // filesystem that causes it to reuse directory entries of deleted // files. Example: // 1. create a file named "test.dat" // note the file's creation date // 2. delete the file "test.dat" // 3. wait a few seconds // 4. create a file named "test.dat" // the new file will have the same creation // date as the old one. // We work around this bug by taking the file's // modification date as a reference when the // file is empty. if (sizeImpl() == 0) _creationDate = File(path).getLastModified(); else _creationDate = File(path).created();
However this fails in the case of an application that is stopped and started multiple times within the log rotation period.
The application is started on the first of the month, and creates a log file with correct creation and modification dates. The application can be stopped and started up until the log rotation period (let's say one day). At the one day point, the log file will be rotated, and a new file created with the same name. Due to Windows "tunnelling", this file will be created with a creation date the same as the old rotated file, and a modification date that is correct. The above excerpt of code accounts for this, and uses the modification date for empty files.
The problem is now if the application writes to the log file, then exits. When the application starts again, it will see a logfile that is not empty, and will grab the creation date instead of the modification date. The creation date however is greater than the rotation period and the file is immediately rotated again. All subsequent starts of the application will cause the logfile to be rotated due to Windows continuing to use the original creation date on the new files.