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

Subject: Re: [boost] [log] Patch: rotating file collector
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2013-05-02 08:09:13

On May 1, 2013, at 8:53 AM, Andrey Semashev <andrey.semashev_at_[hidden]> wrote:

> On Wednesday 24 April 2013 18:09:37 Alexander Arhipenko wrote:

[snip]

> 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.

>>> 5. You don't seem to rename the collected files when the file pattern contains date/time (see date_rollover_policy). Is that right? Obviously, you will only have the date and time point of the rotation and not the file creation.
>> You're right that collected files are not renamed for date/time patterns. I don't have any strong opinion about whether file name should indicate file creation or file rotation time.
>> However, gut feeling inclines me to the second case (file rotation time).
> 
> I think, most, if not all systems I had experience with (including proprietary  developments) put file creation time in the file name. And this is quite  expected, I think. I mean, if you're looking for a file that might contain  logs for a specific time point, you would typically assume the file name to 
> indicate the beginning of the time frame and not the end of it.
> 
> Of course, we could put both time stamps into the file name, but that's  another story.

I agree that the creation date/time makes the most sense. Both creation and close dates/times would be ideal, but with a set of creation-dates/times-only files, the end date/time can be inferred from that on the next file.

>> On the opposite, I have following real life use case.
>> User logins to system and wants to monitor events for day 23.
>> There are 2 log files in the log directory: file.log and
>> file.log.2013-04-21. If filename indicates creation time, then it's hard to guess what file to look at: records could be found in both files.
>> If 2013-04-21 indicates rotation time, then it's clear that the record for day 23 is in file.log.
>> 
>> It will be interesting to hear opinions from you.
> 
> If I have a login date (20013-04-23), I would look into file.log.2013-04-21  first. Call it whatever you like, but my intuition tells me that the file name  indicates the date of the file creation. :) Also, the last modification time  might give you a hint on when the file ends, although it depends on your file 
> manager how apparent this attribute is.

If the current file has no date/time in the name, that's a problem. An entry for the 23rd can only be located by searching. I'd start by running head on the most recent file. If the first entry is past the desired time, then I'd know to look in the file with 21 in the name.

> You can avoid the confusion if you name the active file with its creation time  as well (which is what Boost.Log does, currently). So if you have 
> file.log.2013-04-21 and file.log.2013-04-25 then it's pretty obvoius which  file contains the records you seek.

Right

> 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. :)

___
Rob

(Sent from my portable computation engine)