Re: [boost] [log] Patch: rotating file collector

On Thursday 02 May 2013 08:09:13 Rob Stewart wrote:

On May 1, 2013, at 8:53 AM, Andrey Semashev wrote:

...

I would also prefer another name for the new collector since I'm afraid "rotation" term would become too overloaded since it is used not with regard to rotating files in the sink backend. "Stacking" collector maybe? "Rolling" collector? I'm ignorant of you library terminology, but "rotation" is appropriate if you maintain a set of numbered files, so a given file's number changes as it ages. In that case, the contents rotates through the numbered filenames.

OTOH, if the files are dated, then they are not renamed when a new file is created, so the log output spills over into a new file when the date changes. In that case, "rollover" makes sense.

The library supports both date/time stamped files and file counters. And when the file is rotated, it is simply put into the storage, and a new file name is generated (with the new timestamp and/or the next counter value). This process of switching the actively written file is called "rotation" (at least, that's the meaning I put into the term). English is not my native language, so there may be a better word for it. What Alexander suggested is a different mechanism of storing the files, when the previous files are renamed (their counters are incremented) and the new file is named so that it has the least counter value. So the storage behaves kind of like a stack of files, that's why I also suggested "stacking" collector. But in any case, whether or not this new mechanism is used, file rotation will still take place, so I think it is a good idea to name the collector differently to avoid the confusion.

...

Actually, I think if you open it on Windows while the sink attempts to rotate it, you can screw up the rotation and loose some records while the sink tries to recreate the file. I haven't tried this but if I'm right then you're basically not recommended to open the file while it's being written. You must allow for following the current file or reading previous files, at all times, as much as possible. What's not possible just takes more effort. :)

I agree. That shouldn't be a problem on systems when an open file can be deleted or renamed, which covers all UNIX-like systems, if I'm not mistaken. I have always been annoyed with the different behavior of Windows in this regard, especially in conjunction with some antivirus services that love to poke their noses into files. In fact, that was one reason I tried to minimize the number of file system operations that need to be performed on a file rotation. Anyway, I'll need to try this next time I'm running Windows to see the impact.