Previously, text_file_backend would generate a new file name when the file
name pattern contained a file counter placeholder, which prevented appending
to the file. Appending was only possible when the active file name was
stable across process restarts (effectively, this prohibited the file counter
to be used in the active file name).
This commit adds support for appending in such configuration. The file
collector has been updated to return the last found file counter during
filesystem scanning, and the sink backend doesn't increment it when the initial
file is opened, when appending is enabled, and when the file to be opened
exists and, if file collector is used, is in the target storage of the file
collector. In all other cases the file counter is incremented, which leaves
the behavior unchanged.
Closes https://github.com/boostorg/log/issues/179.
This prevents the file counter from being reset to zero if scan_for_files
is called multiple times, and subsequent calls don't find any new files.
Reported in https://github.com/boostorg/log/issues/179.
This ensures that the writing position is actual immediately after the
log file is opened for appending. This fixes incorrect accounting for
the initial file size with MSVC and possibly other compilers.
Closes https://github.com/boostorg/log/issues/151.
The file counter gets incremented when a new file is opened. Since the
target filename was generated later, on file rotation, the target filename
got the next value of the counter. This caused some values of the counter
being skipped when the application restarts and scans for the previous
log files.
Fixes https://github.com/boostorg/log/issues/125.
If the log file has not been created (e.g. when there are no log records
written yet), rotate_file could throw as it attempted to rename the file
to the target file name before rotation. The check for file presence that
was intended to protect from this was made later on, before the file collector
is invoked. This commit moves the check before renaming.
Since day_kind is enum, it may be represented by a signed integer type.
Some compilers (e.g. MSVC) use sign extension when loading the day kind
field from the bit field, which corrupts the monthday value (which is 2)
and makes the rotation never happen. Fix this by using an unsigned type
to store the day kind and then cast the value to the enum.
Also, rearranged the bitfields for slightly better codegen.
Fixes https://github.com/boostorg/log/issues/98.
Text ostream, file and multifile sink backends now support controlling trailing
newline insertion after every log records. The supported modes are described by
the auto_newline_mode enum. The behavior can be controlled via the same-named
named parameter, a set_auto_newline_mode call or the AutoNewline parameter
in the settings.
The default behavior has changed from the previous releases. From now on the
trailing newline will only be added if there isn't one in the formatted log
message already.
If a file name pattern ended with a placeholder, e.g. a file counter, file names
fitting that pattern would not be matched by scan_for_files, leaving such files
unmanaged.
Fixes https://github.com/boostorg/log/issues/78.
This allows to have different file names when actively writing the log file
and when rotating. In particular, this solves the problem with appending
to the previous file, when the log files are also collected and are supposed
to have distincs names.
If the text file sink backend used the file that was previously scanned
by file_collector as an old log file, on rotation the collector would
store a duplicate of the file info. If the file was removed due to
storage limits, the file info would still be stored despite the file
being deleted.
Also, in case if a file that is about to be rotated is deleted, don't
hard fail with an exception. This may happen if another process have deleted
the file or Boost.Log itself has. The latter can happen if multiple sinks
write directly into the common target storage and one of them invokes
file rotation, which due to the storage limits delete the file that
is currently being written by the other sink.
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.
