Some types of malformed messages could trigger an off-by-one error
(for example, \0 or \n as the last character, and generally control
character escaption is questionable). This is due to not strictly
following a the \0 or string counted string paradigm (during the last
optimization on the cstring class). As a temporary fix, we have
introduced a proper recalculation of the size. However, a final
patch is expected in the future. See bug tracker for further details
and when the final patch will be available:
http://bugzilla.adiscon.com/show_bug.cgi?id=184
Note that the current patch is considered sufficient to solve the
situation, but it requires a bit more runtime than desirable.

If multiple files try to create a directory at (almost) the same time,
some of them may fail. This is a data race and also exists with other
processes that may create the same directory. We do now check for this
condition and gracefully handle it.

The old code looks a bit "strange", though not necessarily incorrect.
The new code looks correct and is probably less irritating during bug
hunting.

However, in practice the loader initializes them with zero, the
desired value, so there were no actual issue in almost all cases.

The previous fix fixed an issue with on/off bying used in the exact wrong
semantic. It corrected the situation, but failed to fix one spot where the
wrong semantics were used. This is done with this commit.

Note that this is NOT a bug seen in any released version.

currently being accessed buffer could be overwritten with new data.
While this probably did not cause access violations, it could case loss
and/or duplication of some data (definitely a race with no deterministic
outcome)

predicate was not properly checked when waiting for the background file
writer

Internal data structures were not properly protected due to missing
mutex calls.