Open TIPConsulting opened 3 years ago
This sounds reasonable; I need to check if it is possible to create a file in a 'lazy' manner when 'FormatLogFileName' delegate is provided.
I've just checked the code and it seems when logger is initialized it creates an empty file but it is resolved with 'FormatLogFileName' delegate - so it is a bit unclear how log file may remain empty (only when app doesn't write anything to a log for a long time?..).
I may explain why a log file is opened/created on the initialization stage: this is performed from the app main thread, and if target folder is not writable exception will block app start. I think current behavior should be preserved, and lazy log file creation may be forced with a special option only when needed.
so it is a bit unclear how log file may remain empty (only when app doesn't write anything to a log for a long time?..).
That is essentially the problem, yes. I like to have granular log file names that includes a timestamp with seconds. So the calculated file name changes by the time that a log is written.
I like to have granular log file names that includes a timestamp with seconds.
wow, that's pretty unusual usage of the file logger (a new file for each second!). I think a new option smth like 'LazyFileOpen' may be introduced to control a log file opening (init time vs first log message).
The core tool creates a new empty file as soon as the logger is initialized. This works fine if you use a non-granular naming scheme, like "LogFile.log" because all of your logs will then be appended to the same file. However, when using granular file names - like adding a timestamp to the file name - the initial log file remains empty. This adds noise to the log output folder.
It would be very helpful if files were only created when a message is being written