Lines 30 - 40 indicate an assumption that someone made as to how file access works. I do not know if they ever proved their assumption at the time, but under windows 7 and .NET framework 4.0, the assumption is incorrect.
The only time you that you may "move" an open file, is if it was opened with FileShare.Delete. log4Net never uses FileShare.Delete so the entire premise used in RFA is invalid. When I looked at this code a few years ago, I thought it was overly complicated and obtuse. Since spending the day with it today, and discovering the invalid assumption, I stand by my original opinion. After looking at the 14 or so bug reports against RFA and remembering a few that I never submitted, I think RFA needs a major simplification via a rewrite to better handle gaps in the file names/numbers etc. There are times that it will not delete old files on starting an appender because there are gaps in the names. It also assumes that the name of a backup file == the number of backups present. That is just plain wrong because of gaps. I do not know where the gaps come from, but I have seen them many times over the years and of course a human could create a gap be simply deleting a file. Bottom line, the current plan for rolling is not robust. Many times RFA lower cases a filename, but it is not consistent. It needs to be consistent either as all lower or mixed as supplied by the configuration. Rewriting and proving all scenarios in RFA will take a bit of time. Just doing the testing along is over a week's worth of effort. I cannot not even estimate what NUnit tests will take to write. I am open to suggestions as to what features to add/delete from a rewritten RFA. I know many people, including myself, have wanted a max number of files per time increment when rolled by size and time. ---------------------------------------------------------------------- Roy Chastain
