7 Replies Latest reply on Jun 22, 2012 3:45 PM by philmodjunk

    'false file damaged' report

    Crispin

      Summary

      'false file damaged' report

      Product

      FileMaker Server

      Version

      12.01

      Operating system version

      osx 10.7.3

      Description of the issue

      I get damaged file emails sent by server when swapping over versions of a file

      Steps to reproduce the problem

      Sometimes I want to role back a file to a backup. When I do this I do the following:

      Close the file on server

      Tell server to remove the file

      Copy the backup to my desktop (not sure I really need to do this)

      Upload the copy into FMS12


      When I do this

      The file upload goes OK but the file is infact closed (does it remember this status from the 'close' above?)

      AND (And this is the alarming thing)

      The sever sends a an email out saying:

      "FileMaker Server 12.0.1.178 on filemaker-12-hosting.co.uk reported the following event:

      2012-05-25 09:50:05.730 +0100Error618filemaker-12-hosting.co.ukDatabase or temporary file "filemac:/Raid Disk/Library/FileMaker Server/Data/Databases/STV/STV sales tool cloud.fmp12" is damaged and has been closed. (20401)"

      I hope this is not true!

      Expected result

      No error email and the file to be open after uploading it

      Workaround

      None

        • 1. Re: 'false file damaged' report
          TSGal

          Crispin:

          Thank you for your post.

          After closing the file in FileMaker Server 12, the Admin Console should show "Closed" for the file.

          If you then move the file to the Desktop, the file should then disappear from the Admin Console.

          If you copy the old file into the Databases directory (STV subfolder), the file should then appear in the Admin Console as "Closed".

          When you try to open the replacement database in the Admin Console, is this when you get the error message?  If so, are you able to open the file with FileMaker Pro?

          TSGal
          FileMaker, Inc.

          • 2. Re: 'false file damaged' report
            Crispin

            Hi

            In clarification

            I did not move the file to the desktop. I told FMS to move it to it's removed folder with the menu option FMS provides.

            The file I am moving to the desktop is the backup version

            I am using the server tools (upload) rather than copying any files manually into the databases folder

            Crispin

             

            PS It seems to me FMS has not cleared the closed status from athe file when removing it and so when an identicaly named file arrivins in the same location the system gets confused. I hope the message about damage is wrong!

            • 3. Re: 'false file damaged' report
              TSGal

              Crispin:

              Always make sure the file is closed before moving it.  Otherwise, if you replace with another file of the same name, any information that is cached may overwrite data in the wrong location of the replaced file and damage the file and possibly render it useless.

              TSGal
              FileMaker, Inc.

              • 4. Re: 'false file damaged' report
                Crispin

                Are you aware that I am doing nothing of the sort and that FMS is moving it with the action FM have provided in the actions menu?* This function does not permit the files removal until the file is closed.

                 

                C

                 

                * My first post states "Tell server to remove the file"

                • 5. Re: 'false file damaged' report
                  TSGal

                  Crispin:

                  Thanks for the clarification and confirmation.

                  For background information, when a database file is open, a flag is set showing the file is now open.  When you close a file, that flag is reset to closed.  That way, if the file crashes when it is open, and FileMaker Pro tries to open the file again, it sees the flag was still set to open, so FileMaker will display a message that the file was not closed properly and the file integrity is checked.  Therefore, once you close a file, and move it back into the Dtabases folder, FileMaker Server will see the flag in the file is set to closed.  When you select "Open" in the Admin Console, the file is open and the flag is set.

                  That is one reason why I wanted you to try opening the file locally in FileMaker Pro.  That is, to see if you get the message that the file was not closed properly.

                  Have you tried to recover the file?  If so, did any errors occur?

                  TSGal
                  FileMaker, Inc.

                  • 6. Re: 'false file damaged' report
                    Crispin

                    No I did not check and if it were corrupt then I guess I'd know by now. It seems clear to me that FMS failed in two ways.

                    1) When I remove a file a registers as to it's status should have been cleared.

                    2) On loading a new file of the same name FMS should check and clear any previous status.

                    I'd say from what I observered neither was done and so FMS issued a false report. I will test if this is repeatable. Have you?

                     

                    C

                    • 7. Re: 'false file damaged' report
                      philmodjunk

                      if it were corrupt then I guess I'd know by now.

                      Not necessarily, hence it is a very good idea to use recover to check just to be sure. File corruption can take many forms and it's not at all unheard of (though uncommon) for damage to lie hidden until just the right (wrong?) interaction with the file trips over the damage. I've seen cases where users have checked sequential backups with recover and found that they had to go back many backups until they found a copy that did not report an issue when recovered even though they encountered issues with the file only recently.

                      Things to keep in mind about Recover:

                      While Recover almost always detects and fully corrects any problems with your file...

                      1. The recovered copy may behave differently even if recover reports "no problems found".
                      2. Recover does not detect all problems
                      3. Recover doesn't always fix all problems correctly
                      4. Best Practice is to never put a recovered copy back into regular use or development. Instead, replace the damaged file with an undamaged back up copy if this is at all possible. You may have to save a clone of the back up copy and import all data from your recovered copy to get a working copy with the most up to date information possible.