It most certainly does as the centralized processes like filtering now can run concurrently. You need to change the counterlogic to minimize open file conflicts.

For the last five years we have successfully used the Mercury policy mechanism to invoke an external process which checks all emails for viruses using the Computer Associates antivirus scanner.

This process interacts with a number of external files. Most obviously, and in order to work at all, it must create the result file when required and delete the sentinel file on completion. In addition it maintains a counter of the number of times which it has run since installation and creates a numbered log file for every virus infected message detected.

A problem has arisen after the upgrade from Mercury version 4.52 to version 4.62. It seems that sometimes the counter files become corrupted, which causes a reset to zero. On other occasions some of the log files are found to be garbled. In particular, occasional log files appear to contain the concatenated results of two scanning processes. These phenomena strongly suggest that in the current version Mercury is allowing more than one instance of the policy process to run simultaneously.

Is this likely, and if so how can we prevent it?

DM

I can't be sure that this effects policy handling as you suggest, but the release notes for version 4.61 include the following:

"Threading in the core module  In the past, the Mercury core module has been single-threaded (meaning that it can only ever be doing one thing at a time). With increasing processing of mail via external processes such as Mercury policies, SpamHalter, Content Control, filtering rules and so on, the time it takes to process a message in the queue has been getting longer and longer. As of v4.61, the Mercury core module now supports limited threading (it runs up to seven worker threads), which significantly improves queue throughput on heavily-loaded systems."

If you can't switch to using a non-logging configuration with the CA scanner, you could use the integrated Clamwall together with Clamav, which is not affected by this change.  (There may also be command line scanners from other companies which would work, but I stopped using them some time ago and have no current experience.)