Hi Andrey, what's the status on log file appending? I've done some searching and testing for a few hours, but cannot find a solution. You suggest here, here and in the changelog here ("Added Append configuration file parameter for text file sinks...") that this might be present in the latest version of the logging library, but I just can't figure it out.
I did some tests using the 'add_file_log()' function. Findings:
When the 'target' keyword is left out, and open_mode is set to std::ios_base::app, log messages do get appended to the text file. This made me happy for a while until I realised rotation did not work at all
I managed to sort this out by setting the 'target' keyword as suggested here, but then a new text file was created each time the program was run (as you have mentioned in other posts)
I tried turning off the scanning by setting scan_method to no_scan, but this caused an access violation (as you have also mentioned elsewhere)
I don't know what to try next. I also have a problem where the log file is only written when my program is closed, instead of whenever a message is written (as I thought would be the case due to auto_flush being set to true). I'll figure that one out later though.
Any help or update on the log file appending would be really appreciated
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There is a fundamental controversy of requirements of appending to the old file and log rotation. After the file is rotated, it cannot be appended to, unless rotation doesn't actually move the file anywhere. Then there is the issue with file names tagged with a timestamp - every time the sink opens the file its name can be different and appending won't happen. So the bottom line is that appending works in a fairly limited set of cases, and that is unlikely to change in the near future because, well, I don't see a way around it.
I don't have an advice for you since I don't know what you're trying to achieve. But if you need file rotation then the only way you can append to the old file is to make the target directory the same as where the log file is written.
Regarding the crash when you turn off the target directory scanning, that shouldn't be happening normally. Could you provide more details?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, here is what I really want: a real-time view of all log messages in a log viewer, which also includes past logs.
I am currently using 'Log4View' - it is the only free viewer I have found that nearly lets me do this. It will load all rotated logs, and keep real-time track of one log file. This is great until the log file gets rolled over.
I'm using a 'hack' solution now, where I have open_mode set to append, no target, and a huge rotation size. I make sure not to roll over the log file, so I basically have what I want - continuous logging and all my history.
You are actually right about my desire for appending the log being nonsensical. The only benefit that would give is to maximize the space used by the current log file before moving on to the next, which isn't necessary.
Now I think about it, the real solution I am looking for is one of these:
A log viewer that can automatically read rotated files, or
The ability to rotate files in a different way: by saving older files in logname_*.log instead of newer, so the current log file is always logname_0.log. This will play nicely with most of the free log viewers I've found
Regarding the crash, it happens when the program tries to overwrite a log saved in the 'target' folder. This happens when I have scanning turned off and open_mode set to append.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That alternate rotation strategy was actually requested a few times. I'll probably implement it some day, although it will be significantly more fragile than the current scheme.
As for crash, it'd be great if you could create a compilable code sample that shows it and create a Trac ticket.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Andrey, what's the status on log file appending? I've done some searching and testing for a few hours, but cannot find a solution. You suggest here, here and in the changelog here ("Added Append configuration file parameter for text file sinks...") that this might be present in the latest version of the logging library, but I just can't figure it out.
I did some tests using the 'add_file_log()' function. Findings:
I don't know what to try next. I also have a problem where the log file is only written when my program is closed, instead of whenever a message is written (as I thought would be the case due to auto_flush being set to true). I'll figure that one out later though.
Any help or update on the log file appending would be really appreciated
There is a fundamental controversy of requirements of appending to the old file and log rotation. After the file is rotated, it cannot be appended to, unless rotation doesn't actually move the file anywhere. Then there is the issue with file names tagged with a timestamp - every time the sink opens the file its name can be different and appending won't happen. So the bottom line is that appending works in a fairly limited set of cases, and that is unlikely to change in the near future because, well, I don't see a way around it.
I don't have an advice for you since I don't know what you're trying to achieve. But if you need file rotation then the only way you can append to the old file is to make the target directory the same as where the log file is written.
Regarding the crash when you turn off the target directory scanning, that shouldn't be happening normally. Could you provide more details?
Ok, here is what I really want: a real-time view of all log messages in a log viewer, which also includes past logs.
I am currently using 'Log4View' - it is the only free viewer I have found that nearly lets me do this. It will load all rotated logs, and keep real-time track of one log file. This is great until the log file gets rolled over.
I'm using a 'hack' solution now, where I have open_mode set to append, no target, and a huge rotation size. I make sure not to roll over the log file, so I basically have what I want - continuous logging and all my history.
You are actually right about my desire for appending the log being nonsensical. The only benefit that would give is to maximize the space used by the current log file before moving on to the next, which isn't necessary.
Now I think about it, the real solution I am looking for is one of these:
Regarding the crash, it happens when the program tries to overwrite a log saved in the 'target' folder. This happens when I have scanning turned off and open_mode set to append.
That alternate rotation strategy was actually requested a few times. I'll probably implement it some day, although it will be significantly more fragile than the current scheme.
As for crash, it'd be great if you could create a compilable code sample that shows it and create a Trac ticket.