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

Subject: Re: [boost] [log] Patch: rotating file collector
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-05-02 08:54:29

On Thursday 02 May 2013 08:09:13 Rob Stewart wrote:
> On May 1, 2013, at 8:53 AM, Andrey Semashev <andrey.semashev_at_[hidden]> 
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.