RollingFileAppender overwrites file if already rolled by another process

["Walden H. Leverich" <Wa...@TechSoftInc.com>]

I've been playing with a test case all afternoon and I think there's a bug in the RollingFileAppender roll process when rolling by date.

Specifically in the RollOverTime method the call to SafeFileOpen (line 1209) should pass true not false in the append parm, no?

Current (1.2.12) code is:
       if (fileIsOpen)
       {
              // This will also close the file. This is OK since multiple close operations are safe.
              SafeOpenFile(m_baseFileName, false);
       }

but shouldn't that be:
       if (fileIsOpen)
       {
              // This will also close the file. This is OK since multiple close operations are safe.
              SafeOpenFile(m_baseFileName, true);
       }

The problem I'm seeing is that if another process has already rolled the file (assuming a locking model other than exclusive) then the second (and subsequent) process to perform the same "roll" will attempt to open the new file with a false for the append parm and thus overwrite anything in the file already. This isn't likely seen when rolling by size as you'll just increment the file #, but when rolling by date both processes calculate the same new file name and the last one in wins.

In my limited testing the change from false to true above fixes this, but I grant I'm not an expert on log4net. Thoughts? Am I missing something?

-Walden


--
Walden H Leverich III
Tech Software &
BEC - IRBManager
(516) 627-3800 x3051
WaldenL@TechSoftInc.com<ma...@TechSoftInc.com>
http://www.TechSoftInc.com<http://www.techsoftinc.com/>
http://www.IRBManager.com<http://www.irbmanager.com/>

Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)

RE: RollingFileAppender overwrites file if already rolled by another process

[Dominik Psenner <dp...@gmail.com>]

Hi Walden,

>The problem I'm seeing is that if another process has already rolled the 
>file (assuming a locking model other than exclusive) then the second (and 
>subsequent) process to perform the same "roll" will attempt to open the new

>file with a false for the append parm and thus overwrite anything in the 
>file already.

That's a decision that was made at design time. :-) Without taking a closer
look at it, I would guess that 's/false/true/' wouldn't work either. It
would at best truncate the file, too. At worst it would raise typical race
conditions (random behaviour) because context switches can happen at every
non-atomic operation of all processes involved. The only real solutions are
to either:

1] use exclusive lock when logging into the same file from several processes
2] configure an event/rcp appender that invokes a file appender which is the
only one appending to the file

JMTC and comments welcome.

Cheers,
	Dominik