OSX Server sporadically damages files when closing

[paulage77]

Whenver we shut the server down that is hosting 25 files one or more become damaged and have to be recovered! It's crazy, it's seems to be random files. The log appears to be closing files then confirming the closure and usually one file ends up with a could not close possibly damaged error. What the heck is happening here!!!

Anyone else see this?

[marcd]

Had the same problem about a year ago. 78 files hosted OSX, FMP Server 5.5 733Mhz G4. Spent hours on the phone with FileMaker. Their suggestion - REBUILD ALL FILES FROM SCRATCH. Finally gave up and went back to OS9 no problems since.

[paulage77]

That's insane. What do they mean by REBUILD ALL FILES FROM SCRATCH? Clone and import data or what?

Switching back to legacy software as a work around isn't a very optimal work around. Hopefully FMI is addressing this issue. Anything about it in the release notes?

[marcd]

I was told to rebuild from the ground up (recreate all fields, relationships, scrips etc), then import the old data. I had already tried cloning and importing, it seemed to help a bit but did not solve the problem.

It all started when we had to force quit the FMP Server daemon. Tried cloning files from back-up and even taking the old FMPro 4 files and reconverting them to 5.5. Nothing worked except going back to 9.

I would love to be able to use OSX since it provided greater speed to the network. I'm planning on ignoring it until I am forced to switch to OSX, then trying to fix it then.

[kennedy]

Which version of OS X.

I've been using FMS 5.5 with OS X without incident. [sound of knocking on wood]

[marcd]

OS X 10.1.5

[Guest]

luckily no problems with OSX 10.2.1, but then i have not shut down the server since final installation.

[the walker]

i had the same prob about five months ago with osx

it totally ruined my whole db with 60 files and a years work

luckily i had backups

i found that it may of been becuase i had underscores in the files names, i got rid of these and any other special characters(including spaces). it has been working like a charm ever since, touch wood it will keep it up.

[Matthew F]

I have been having this problem ever since purchasing FileMaker Server 5.5. It has never run reliably and allowed us to host files. Files randomly become "damaged" when the server is shut down. Sometimes the server shuts down for no apparent reason. At other times the server refuses to shut down and forcing it to quit is an almost guarantee to induce "damaged files". The files seem to work fine when opened directly from FileMaker Pro v.5.5 or v.6.

Yesterday I called FileMaker support and they suggested installing their updater 5.5 v.2. I went one step further. I reinstalled the original server software from the disk and then used the updater. This seems to helped for about 24 hours. Unfortunately I've discovered that the server is not getting all of the relationships correct and it once again refuses to shut down.

This without a doubt the most unreliable software I have ever encountered and is a far cry from the relative reliabilty of FileMaker Pro software itself.

[paulage77]

Hey mfero, where are you in Seattle... that is where I am.

Anyway, I saw the same thing in Server with it messing up relationships! I didn't attribute it to the upgrade to 5.5 but was able to reproduce it by simply adding a new relationship to one of the databases while the file was being served. Then closing and reopening the files totally messed up the relationship among all the databases. The work around is to shut down the server and add the relationship via FileMaker Pro WITHOUT the file being served. Problem is the files get damaged when closing!! It's a conundrum. So, what we have to do is back up files everytime before closing, then close and work on the backed up files and subsequently host those files. We've finally automated the process, but it's way way more work than it should be. I have also spent time talking with FileMaker about the issue to no avail. The OS X 5.5 Server is very reliable for us if we don't have to shut it down. If we do, then look out all hell breaks loose.

[Matthew F]

Backing up all of our databases strictly according to the article I previously cited was of no avail as our files quickly became damaged again. FileMaker support today suggested following the guidelines listed in their "Best Practices" white paper: http://www.filemaker.com/downloads/pdf/fms_best_practices.pdf

Currently we have shut down AppleTalk, Filesharing and all other network activity on the server computer. It is clear that the server is trashing files and I'm guessing that it can't negotiate network connections properly with other processes. Currently we've been able to go a whopping 6 hours without a disaster. Time will tell...

If I encounter damaged files I now immediately shut down the server, reboot the system and replace everything with backups. Opening a file directly with FileMaker Pro on the server computer ususally corrupts files. Opening the files remotely using the "Hosts" button on the server computer seems fine.

[Dave Graham]

Have you upgraded to FMS 5.5v2? Are you using the build in backup scheduler or a shell script?

The only thing that can cause what you are seeing is another process modifying the files while they are in use. Here's a couple of things to look for:

1) The shared database directory (where you have all of your files) should NOT be available via file sharing!

2) There was a possibility of conflict between the backup scheduler and the cache flush where the cache flush could accidentally resume files while they are supposed to be paused for backup. I think it was fixed but can't be sure. Try turning it off it it isn't already.

"If I encounter damaged files I now immediately shut down the server, reboot the system and replace everything with backups. Opening a file directly with FileMaker Pro on the server computer ususally corrupts files. Opening the files remotely using the "Hosts" button on the server computer seems fine."

If I understand what you are saying here, then this is the cause of your problems. You can NEVER open the files locally when the server is running.

[Matthew F]

Hi Dave,

Thanks for the feedback. In response to your questions: Yes, we are running the upgrade v.5.5.2. As I stated in my last post we made changes according to the "Best Practices" white paper last week and so far we've been able to go a whole week without corrupting files. The changes that we made included turning off appletalk, turning off personal file sharing, and stopping all network activity on the Server computer other than Filemaker Server. Although we had filesharing turned on before we never attempted to access a database this way while it was being hosted by the server. Neither did we access a file locally when the server was running. My previous statement about this was a warning to others since we quickly learned that this has bad results.

Making these changes (no Filesharing, Appletalk off, etc.) appears to have cured our problems, although I'm not sure which sort of network activity was the culprit. :

[dkemme]

On a completely different vein:

I had problems with FMServer shutting down intermittently after upgrading to a new G3. Turned out we had some bad cabling in our Ethernet network that was discovered only after certifying network from cable end to cable end. The new G3's Ethernet card was more sensitive to the bad cabling and would cause the crash. This took 6 months to figure out and many lost nights of sleep, all for some cheap cabling that found its way in the office.

[djgogi]

FMI is aware of the problem. (Well, they just waited a little bit to long to admit the existenz of it).

You could check TN on FM site

http://www.filemaker.com/ti/108428.html

Dj

[Matthew F]

Thanks for the information Djukic. We now make sure that we shut down our databases using the Remote Administration file scripts prior to shutting down our server for maintenance.

A recent problem arose which is illustrative: Our main data file suddenly became corrupt and inoperable when it was in use. The server no longer hosted the file nor did show up as a file which could be closed using the Remote Administration file. We went ahead and "closed" all of the other open files. Nonetheless, the server refused to shut down and we had to force restart the server computer. This ended up damaging and rendering inoperable every single one of our data files even though we had supposedly "closed" them already. Fortunately we have daily backups to resort to.

Filemaker really needs to develop a way to gracefully stop the server when it is hung up on damaged files. If the server hangs I would go ahead and "close" all of the undamaged files and copy them if necessary before rebooting!

[paulage77]

At least with OS X, it is a good idea to back up all files before doing anything, especially shutting down the server. We set have it set up here to back up all files to a fire-wire drive 6 times through-out each day in case anything happens.

[Matthew F]

We've recently become aware of a new type of file damage that can subvert efforts to backup data. Our database is backed up to the hard disk daily and to CD-ROM weekly. Our server was in continual use for one month without being shut down.

Despite the fact that the server was able to host the database without troubles at some point the files and all of the backups became corrupted such that they could not be opened or recovered. We had to go to backups over a month old to find versions that were openable. Interestingly, when I went tested our backups I found that the first sign of damage that occured was that clones from the backups would not open even though the original backup was openable. Attempting to open clones of the backed up file gave an error message to the effect "FilemakerPro does not recognize this version ??.? of this filemaker file". Subsequent backups became even more corrupt such that they are not openable or recoverable at all.

We will now test our backups to be sure that they are functional. Just because the server keeps working doesn't mean your files are not corrupt. When we shut down our server we follow FileMakers recommendation of first closing files remotely. It might seem that the damage occurs when the server is shutdown but this might just be when it is first noticed since the files are not openable. Every time we've been able to open or recover damaged files we have never found corruption or loss of data.

[jfmcel]

I've suspected that this might be the case. I unfortunately have seen this once before and was hoping it was anomalously.

I have seen recommendations to run the recover command several times on a file... Maybe an applescript scheduled to run after backing up could catch the corruption before it goes on for too long, but this is above and beyond what is reasonable.

I have taken to doing all my development off-line and re-importing the data. This greatly slows my development cycle, but seems to work.

No question "FileMaker

[paulage77]

To get around this, I have backups take place each night, then applescripts set on on cronjobs that shut down server, upon up the back ups in FM Pro and make sure everything comes up okay by running test FM scripts. Once these pass, then FM PRo is closed and the backups are copied to another drive. From there, the old hosted files are corrupt because closing the server damages them. So, then another applescript triggers and copies the back-ed up databases over the damaged ones and Server is re-opened. Ah, but remember to make sure the back-up actually happened before shutting down server(which doesn't always happen) lest you be left with a bunch of damaged files that need to be recovered in the morning.

All of these tasks and applescripts have taken weeks if not months of development and debug. A completely un-reasonable thing to have to do to work around FM Server 5.5. It all finally works, but it was a painstaking iterative process, as different things start failing along the way.

[Matthew F]

Thanks for the tip, Paul. Would you be willing to share examples of your applescripts?

At this point I've totally abandoned the Filemaker OSX server because the file corruption just kept happening and demanded too much work to continually repair. In the end it seemed like the server was inducing damage to the files during the nightly backups, which certainly is self-defeating.

I tried out the OS9 version which did not cause any file damage but it was slow. For some reason after running for a few hours the OS9 server would slow down even more -- to a snails pace -- and was basically useless. At the moment we've gone back to using our database from a single workstation which is inconvenient but, hey, at least its fast and reliable!

[paulage77]

Yeah, I'd willing to share scripts. We had the same problem with 9. It was just too slow eventually to be useful so we had reboot. OS X gives us good speed, but so many other flaws. Anyway, just private message and I'll give you some sample scripts.

[ernst]

Well, I have been running MacOS X and FMS for almost a year now, and though it's indeed tricky to start and stop, it has been running well when just left alone.

Setup is an eMac 700 Mhz, hosting 20 files for 15 users, total amount of data about 200Mb.

Backup takes place twice a day to a ZIP drive and a second partition of the internal drive. No problem with that. The eMac is on a UPS and is allways left on.

I did have problems like paulage77 describes when adding files, or temporarily hosting files on a client to make changes. In my experience the best way to resolve such problems was (as described somewhere else in the thread) A. make a backup copy of the files before attempting any recovery. B. recover on a client, don't rely on the server for this! C. open the files ONE time on the client, before putting them back and restarting the server.

Before I switched to X, I was using the OS9 version of the server on the same machine achieving about the same performance. Filemaker Server needed to be the foreground program inthat setup (could this be mfero's problem with the server being slow under MacOS 9 ?)

So, to MHO, it IS a working solution, but needs to be improved a whole lot by our dear Filemaker Inc. on the double!

Regards,

Ernst.