Container Folder - Anti-virus - FileMaker Pro Error
Operating system version
Description of the issue
We were delighted with the option of alternative container folders in the new version. However, we were having an issue with a robot (FM Pro v13) analysing incoming emails/attachments within our CRM solution.
The configuration is
FM Server running on Windows 2012 server with separated hosted database and container folders on an SSD 'D:' drive. As this is a hosted solution we allowed anti-virus (Sophos) to scan the containers folder where the attachments are stored (container fields, stored externally, open storage).
We appreciate that no hosted database should be scanned by anti-virus softer, but as this solution is using FileMaker to import directly from an email server (via Dacons MailIt plug-in), it is very advantageous to have the container stored files scanned.
Steps to reproduce the problem
When a message with an attachment arrives that is marked as a possible virus, the FileMaker Pro client unexpectedly quits, no error message displayed, just reports 'not responding' then quits. We believe this is due to the anti-virus software running on the server preventing the virused file from being written.
If we exclude the external container folder located on the FMS server from the anti-virus protection, then the system works without any problems.
We would expect FileMaker Pro/Server to trap for an error within the container management system, there must be other occurrences when the container field cannot successfully interact with its chosen external file store location - potentially bad blocks or read/write issues.
In our case, we don't actually want the virused file to be retained and due to the nature of the CRM system, if we could continue with the email script, the message and attachment records would be subsequently deleted. However, as FileMaker just gives up, then it effectively crashes the whole system.
We understand that the obvious thing to do is to disable anti-virus scanning of the open container storage folder. However, there is another repercussion of this problem, in that in many cases the FileMaker Pro client will leave the file where the container field is used in an unusable state, with errors such as 'lock conflict(s) with 1 database user(s) Admin - there is no account within this file called 'Admin'.
In this case, the only solution is to restart FileMaker Server but with 78 database files hosted, this is a major problem for us.
Also, as we're allowing all email messages to be processed, turning off the anti-virus would allow storage of viruses on the server. As FileMaker Pro makes extensive use of each client's temp folders, opening of a file from within a container field opens up a good chance of a Filemaker stored file infecting a user's computer.
Exact text of any error message(s) that appear
The client's event viewer reads:
Faulting application name: FileMaker Pro Advanced.exe, version: 220.127.116.11, time stamp: 0x526aac3b
Faulting module name: Support.dll, version: 18.104.22.168899, time stamp: 0x526aa83e
Exception code: 0xc0000005
Fault offset: 0x00098658
Faulting process id: 0x2a7c
Faulting application start time: 0x01cf467cfed821a0
Faulting application path: C:\Program Files (x86)\FileMaker\FileMaker Pro 13 Advanced\FileMaker Pro Advanced.exe
Faulting module path: C:\Program Files (x86)\FileMaker\FileMaker Pro 13 Advanced\Support.dll
Report Id: cafb1260-b270-11e3-b8ef-bc764e08429a
Application: FileMaker Pro Advanced.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: exception code c0000005, exception address 64078658
As mentioned earlier, FMS v13 is running on a Windows 2012 Standard Server, most clients are Windows clients, but some Macs. The robot is always running on Windows.
We have had to exclude the container external storage folder from virus checking. However, we believe this could be error trapped from within FileMaker Server or Pro, as the new containers are brilliant and users will be uploading files to this using the normal methods. Currently, it appears that FileMaker allows a back door to allow files containing viruses to be uploaded to a server.
By putting in an error trap when an externally stored container file is prevented from being written to the storage location, FileMaker would be preventing this without their product just appearing to crash.