4 Replies Latest reply on Mar 27, 2014 1:03 AM by CraftICT

    Container Folder - Anti-virus - FileMaker Pro Error



      Container Folder - Anti-virus - FileMaker Pro Error


      FileMaker Pro



      Operating system version

      Windows 2012

      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.

      Expected result

      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.

      Actual result

      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:, time stamp: 0x526aac3b
      Faulting module name: Support.dll, version:, 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

      Configuration information

      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.


        • 1. Re: Container Folder - Anti-virus - FileMaker Pro Error

               Andy Hibbs:

               Thank you for your post.

               A database file contains information for tables, fields, relationships, as well as data.  Even though a Container field can be set for external storage, it is still part of the database file, and you should not run anti-virus software against the remote Container folder.  I have sent a message to Development and Documentation to determine how to make this clearer.

               As a workaround, export the Container field contents to another folder where you can perform the anti-virus scanning.  If a virus is detected, then you can go into FileMaker Pro and delete the record or clear the Container field.

               Let me know if you need additional clarification.

               FileMaker, Inc.

          • 2. Re: Container Folder - Anti-virus - FileMaker Pro Error

                 I anticipated the 'don't use anti-virus' and appreciate your response.

                 The point I'm attempting to make is that I believe FileMaker could do this better. If you consider how FileMaker manages container fields, a user uploads a file, which could contain a virus, on to the server. When a client accesses this file from FileMaker Pro, it is often downloaded to the FileMaker Temp folder on the user's computer - in this scenario the 'don't use anti-virus' has allowed a potentially harmful file to be spread by only using FileMaker Pro and Server. Personally I think there is a huge difference between data and 'attachments' - could you imagine if the email vendors advice was 'don't use anti-virus' with your email - every computer system in the World would crash.

                 Equally, the result of a virused file being isolated on the server is that the user's FileMaker Pro unexpectedly quits from an exception error. Surely this could be trapped for and solve both problems?

                 The server in questions runs around 78 database files with automatic collection and management of emails. Thousands of records are analysed, so I don't think  manual tracing of a virus is realistic do you?

                 This isn't really a complaint, it is an attempt to raise this with your developers for them to consider - containers are fantastic, but to quote 'with great power comes great responsibility' and FileMaker is providing a medium to transfer files from one computer to another - not just text data. I appreciate the easy way out for FileMaker is to follow the old 'don't use anti-virus' but personally we think you are better than that!

                 Many thanks


            • 3. Re: Container Folder - Anti-virus - FileMaker Pro Error

                   Andy Hibbs:

                   Development would like to get your crash report to see if anything can be done to fix external drive anti-virus protection.  Check your Inbox at the top of this page for instructions where to send the crash report.

                   FileMaker, Inc.

              • 4. Re: Container Folder - Anti-virus - FileMaker Pro Error

                     Hi, thanks for raising this with the Development team, which was always our intention.

                     The Windows FileMaker Pro event logs were included within my original posting. However, as the server is in use for pretty much 24 hours a day from Asia to US, we'll temporarily reintroduce the container anti-virus scan this weekend and attempt to recreate the problem and provide any server and client reports. Part of the problem is that our own computers are protected and purposely handling virused files is a bit of a challenge.

                     If we can replicate we should be able to send over the crash reports from both Mac and Windows clients.