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]>
> > 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
Anyway, I'll need to try this next time I'm running Windows to see the impact.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk