logging : rotation at time strategy

[cdelmas]

Hello all,
I have a question about the RotationAtTimeStrategy. For instance, I start my application at 11:00, and let it run until 17:00. At this time, I stop it, and it won't run until tomorrow. Then, I restart my application at 10:00, and I have a bad surprise: the log file isn't rotated, the same as yesterday is used !

I'm curious, so I went to find the code responsible for that behavior. Then, I found:

Code: Select all


void getNextRollover()
   {
      Timespan tsp(0, 0, 1, 0, 1000); // 0,00:01:00.001
      do
      {
         _threshold += tsp;
      }
      while (!(_threshold.minute() == _minute &&
              (-1 == _hour || _threshold.hour() == _hour) &&
              (-1 == _day  || _threshold.dayOfWeek() == _day)));
      // round to :00.0 seconds
      _threshold.assign(_threshold.year(), _threshold.month(), _threshold.day(), _threshold.hour(), _threshold.minute());
   }


The next rollover is set at "tomorrow",00:00! So it will never rotate my file if I stop my application before!
How can I force the logger to rotate my files every day at midnight or if it is not already done (because the application was off)? Is there another strategy or may I create another strategy class?

Thansk in advance.

[alex]

> How can I force the logger to rotate my files every day at midnight or if it is not already done (because the application was off)? Is there another strategy or may I create another strategy class?

What you can do is add the check for the pFile->creationDate() prior to calling getNextRollover() from mustRotate() and return true if the new file should be created.
It would be nice if you could do it in a universal way (covering all the possible time based rotation cases) and contribute the code back.

Alex

P.S. I'm not sure what side-effects this may produce related to the funny NTFS "optimization" described in LogFile_WIN32.cpp constructor comment.

[cdelmas]

I have another problem, but it would probably be easy to patch. When a file is rotated, it must be destroyed then recreated. Indeed, the roll over will occur every time once the delay is over, resulting in too many archives.

[cdelmas]

>> P.S. I'm not sure what side-effects this may produce related to the funny NTFS optimization" described in LogFile_WIN32.cpp constructor comment.

The funny optimization (called file tunneling, I don't understand why ?!) described in LogFile_WIN32.cpp can be patched using "SetFileTime" :

^Sets the date and time that the specified file or directory was created, last accessed, or last modified.

Code: Select all

BOOL WINAPI SetFileTime(
  HANDLE hFile,
  const FILETIME* lpCreationTime,
  const FILETIME* lpLastAccessTime,
  const FILETIME* lpLastWriteTime
);

^
Doing that way, the file is really a new file !

[alex]

> I have another problem, but it would probably be easy to patch. When a file is rotated, it must be destroyed then recreated. Indeed, the roll over will occur every time once the delay is over, resulting in too many archives.

Look at PurgeStrategy.