Yeah, I'm not sure I implemented it the best way. It was more of a workaround against the current release until similar functionality makes it into the official build, and I posted it at least to make it available to others that could use the functionality now.
When I get more time (might have to be weeks or months), I might have a chance to make a better patch and base it on the newest revision.
As for the digits like .10, .11., etc. Its looping thru the characters from the end of the string looking for either digits or a period. At the time, that was the way it occurred to check if the char was a digit. (Now, I realize I could simply do something like >= "0" and <= "9" or something. But, I didn't test with more than 4... so, I should test that.
When rolling sizes, then the files extensions (.1, .2, .3, etc) are getting renamed. When rolling dates, they aren't, so there isn't any previous file identified.
Actually, there was some code that looked at the system's date modified time, although in a different function in that class.
Your last comment about your idea:
The problem I had was this:
(well, first, files are rolled/renamed in the size functionality, not the date functionality, except for the initial rename from the basefilename to the filename with the date format embedded)
there could be files sitting there that need deleted from a lot longer ago than the MaxDateRollBackups value allows, and these files need deleted (they still exist because, say, the program hasn't been in awhile). So, somehow those files have to be identified. They have the formatted date inside of it. How to find all file with the base filename and a date formatted with that format (and also potentially any size extensions on them)? Some date formats can be difficult to parse from the string back into the date. Especially the ones that spit out long names and such. They can throw all kind of crazy formats into those files. Using a basic * wildcard works easily, but could cause files to be deleted that aren't desired to be deleted. LIke if someone renamed it manually with a descriptive extention to save the file. I'm not sure if it is wise, but to be safe and not delete files that shouldn't be deleted, I figured looping thru the files based on the simple * wildcard, skipping the ones we know are still good within the MaxDateRollBackups and MaxSizeRollBackups limits, we can take the rest, get each ones' modified timestamp, format that timestamp, compare against the formatted timestamp in the filename, if it matches exactly, then it hasn't been renamed, and can be deleted. Also, check the previous check timestamp prior to the modified timestamp, because the file could have been modified as it was crossing the boundary.
I'm just not sure if there are any reasons not to trust the modified timestamp. But I didn't know how else to successfully remove those files, and not files that I renamed.
As a note, my method using modified timestamps may not work well if the date format has seconds or milliseconds in it.
I'm not suggesting log4net do it that way, its just the only way I could do it and correctly have it decide to delete or not delete each file.