I suggest taking a copy of the files down off the server (copy them across the network to your machine) and running a recover on them to see what is reported. As a test, you may even want to put the recovered copy back up on the server to see if can be opened--even if recover does not report detecting any problems.
You may also want to use server Admin to close all the files, restart your server and then see if you can successfully connect to them.
Things to keep in mind about Recover:
While Recover almost always detects and fully corrects any problems with your file...
- The recovered copy may behave differently even if recover reports "no problems found".
- Recover does not detect all problems
- Recover doesn't always fix all problems correctly
- 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.
Thank you, PhilModJunk. I think I might have figured this out earlier but I was misled by NSAutoreleaseNoPool() memory errors in Console. I finally used ScriptDebugger and discovered the problem. I had an initialization script in a subfile that tested the date, and on the last day of the school year it got stuck in an endless loop. I inadvertently broke the script sometime this year but that wasn't apparent until the last school day. I imagine that this endless loop also caused the memory leak, but haven't gotten there yet. Thanks again.