pc Desperate Help Needed - access privileges damaged or tampered with

[TravisB]

Today the machine which was running FM Server crashed, and upon reboot our main database would not open. When saving a copy to the desktop and opening directly it says the file is damaged and cannot be opened. When trying the "recover" command, it comes back with "The access privileges in this file have been damaged or possibly tampered with. Please contact FileMaker Technical Support if the problem cannot be resolved." Most troubling is that all of my backups are also opening with the "The access privileges in this file have been damaged...." I literally don't even so much as have an empty shell of this database, as I did all development as of late remotely (I do have a 1-2 month old version, but a lot of progress has been made on the development since then.) So not only did I lose all the information which was stored in the database, I also lost the design.

 

I did not realize the built in back up service from FMS was inadequate.

 

From what I have found so far, it looks like im pretty well f-ed. Looking for anymore ideas to try and I guess confirmation that I'm screwed. I still need to call FileMaker and see what they say, but I don't really have that high of hopes, but I guess we'll see.

 

Some things that I was doing that probably contributed to this:

 

A) I did do some development while the hosted file was in use by other users - but nothing too extreme or huge sweeping changes, mainly just fine tuning and tweaks

FMS was temporarily on a local computer that was being used for normal day to day stuff as well as running the the database from FMS

C) I have changed privileges while users were using the file (which, I just found out from my 20min of research this probably what caused this issue and is a huge no-no. Why do they even allow it if its such an issue?)

 

Really hoping this is fixable.

[Wim Decorte]

 

 

I did not realize the built in back up service from FMS was inadequate.

 

 

 

I feel your pain but that's not a true statement so I can't let that pass and have others think that it is true.

 

Part of any backup strategy is to test your backups periodically.  You don't want to find out like you just did that they are no good.  Your processes and deployment were inadequate and against best practices - long established best practices I should add.  Best practices developed by people who have been in your position and were hoping to help other people avoid it.

 

As they say: there are two kinds of people in this world: those who have lost data and those who will.

 

Your profile says "FM12".  Have you tried opening the file in FM13?  Have you tried opening them on Windows if you are on Mac or vice versa?

If that all fails then your only hope is to send the files to FMI and see if they can resurrect them.  Those files will not be good to build on but at least you'll be able to get the data out.

The only other guy I know that could possibly help you is Winfried Huslik (www.fmdiff.com).

[TravisB]

I have already emailed Winfried, am awaiting a response. I have not tried FM 13, as I don't have it installed, I also have not tried it on a Mac as I do not have access.

 

As for my comment, and your response, all is fair. If this is a known issue, why FMS wouldn't have a built in feature to check integrity of its backups I do not understand, but I'm also not a programmer or understand the potential complexities so really I suppose one could argue my dissatisfaction with that is unqualified. Your point is well taken, understood and greatly valued. I did not do the proper research on best practices as far as backups go and I knowingly exercised practices, which were to be temporary, but regardless against best practices while others I had no idea about (checking backups for integrity is something I've never even thought of before). I'm not blaming FM, its my fault plain and simple.

 

Either way, lesson learned, I need to figure out exactly what happened, change my methods, ensure this doesn't happen again and simply move on.

 

In the mean time, I need my data back.

 

Any other tips or things to try before I fully give up on recovery is appreciated.

[Steven H. Blackwell]

I regret that your files are so damaged and that you likely have lost a great deal of work.

 

This thread is instructive, however, for all developers.  Best Practices are just that:  practices we know from experience lessen the likelihood the occurrence of incidents such as these.

 

Steven

[TravisB]

Just an update, the file was actually recoverable by using recover in FM 13. The file is still damaged, but the data is at least intact, so thats certainly one big win.

 

I still lost a large amount of development work, but at least I still have the data and a "working" database that I can use to help speed up the re-building processes. Considering where I was 2 days ago, I am very happy with this outcome.

 

I will certainly be advocating as well as exercising best practices from here on out.

 

Big thanks to Wim for helping me behind the scenes, very much appreciated.

[Justin Close]

Travis,

    You mentioned that the FMS backup procedure didn't check integrity...it does - or it can.  There is a checkbox during the creation of the backup schedule to 'verify integrity of backup' or something like that.  Now...I am not 100% certain that that would have caught the problem you found, though.  And that operation does take more processing power and time; your users might notice.  We only verify on our 'Daily' backup that runs at night.

 

There is also an option to create a clone of the file during the backup; this won't preserve the data, but it would preserve any development work that you had done on the file.

 

As another possible troubleshooting technique, though:  have you tried to host the damaged file anyway?  And tried to open the file remotely?  I ran into this problem once a while ago ('access privileges tampered with...'), but I don't exactly recall how we got around it.  It is entirely possible that we just used a backup version of the file.  But I have a nagging memory about just trying to host the file anyway...sorry to be so indistinct.

 

--  J

[TravisB]

Justin,

 

Thanks for the note. I was doing two back ups daily, one at noon and one at 11pm (we close the doors are 5, but often times employees stay late). The integrity option was checked. Last night I moved Server to a dedicated machine and upgraded to FM Server 13 as well as all the machines to FM 13. We have the current file on the server and are using it remotely while I re-develop its replacement and import the data- everything seems to be working fine and I'm crossing my fingers that it'll hold together today and tomorrow and I can finish up the "new" database by Monday morning. Obviously this is not ideal to be using the damaged file and relying on it, but I'm putting in 14+ hr days until the "new" database is ready so the only other choice I see that we have is to shut the doors while its down or use a method to deal with the day to day operations with zero chance of being able to import the data easily once I fix my file.

 

I am saving back ups hourly with integrity check on each one and I am also manually checking the back ups every couple hours just make sure they are opening correctly. I am also saving a clone at each hour - which I wasn't doing before.

[Justin Close]

Glad that you were at least able to recover some of the data.  Too bad that it is a heavy load on you to get things back up and running.  I hope the 'clone' option works out for you in the long run.