If the target directory contained a file with counter value of UINT_MAX in its
name, scan_for_files would always return the counter value of 0, even if such
file also existed in the directory. This caused incorrectly named log files to
appear in the target directory on user's application restart.
Also made sure that the returned counter value is zero if the scanning method
is not scan_matching or the file name pattern does not include the counter
placeholder. The returned counter should not have been used by the caller
in these cases anyway, but the returned value used to be bogus.
This can be useful when the final rotation cannot be performed while global destructors are run (e.g. when a close handler depends on a global state).
It can also be useful to implement file appending with collector set up to a different target directory than the directory the backend writes to.
As requested here: https://svn.boost.org/trac/boost/ticket/8746
this commit introduces the boost::log::keywords::max_files keyword
and implements this functionality in the file collector.
Additionally, the non-keyword make_collector call has max_files added as
a uintmax_t parameter, which has a default value as to not break
existing code.
The purpose of this is to limit the total number of files in the
collected logs. If not specified, the limit will be
std::numeric_limits<uintmax_t>::max(), which is likely greater than the
capacity of the filesystem.
Include winapi/config.hpp as soon as possible; avoid including even
Boost.Config before it so that it doesn't set Windows API version
accidentally by including some third party header. In all source files,
include detail/config.hpp or detail/setup_config.hpp first thing.
Moved all WinAPI config macros to the Jamfile.v2 and removed
windows_version.hpp as it was no longer needed. Also enabled inclusion of
windows.h while compiling the library.
Removed auto-linking with psapi.lib and advapi32.lib as it was no longer
working after ecf3114. Added linking with advapi32.lib to Jamfile.v2.
