As a follow-up to my request, I'd like to thank those that replied. After delving more deeply, we discovered that the Data.fs file had become corrupt. After using fsrecover.py on the file (which cut the last 50KB of transactions), we attempted to resurrect our site. We are somewhat confused as to what happened, but we're trying to find out what. The main reason is that logically, what has happened shouldn't. Here is what we did: With our proper Data.fs file corrupt, we were using an emergency Data.fs which has basic necessities and information. The corrupt Data.fs was named Data.fs.2312 (for when it crashed). The emergency Data.fs was 240MB in size and Data.fs.2312 was 660MB in size. 1) Copied Data.fs.2312 to Data.fs.recover and ran fsrecover.py on it 2) Stopped Zope 3) Moved Data.fs (the emergency copy) to a backup directory. 4) Renamed Data.fs.recover to Data.fs and restarted Zope. The site remained down and inoperative. 5) Stopped Zope. Renamed Data.fs to Data.fs.recover and move Data.fs back from the backup directory. Restarted Zope. 6) Checked the site...and the proper site came up (which was supposed to be in Data.fs.recover). The server has now been running since Friday afternoon with the full site operational. I have tested it. I can add items within the manage screens, the server owner can create export files and the site shows full operatability with the Postgres database behind it. We're waiting for a quiet time to reboot the machine to see if it reverts. We have a suspicion that the site we are viewing is in the cache memory, but as we've never experienced this before, we're kinda stabbing in the dark. Does anybody have any suggestions as to what has happened here? The Data.fs file Zope is supposed to be accessing is the 240MB file. For the life of us, we're stumped. Any ideas, suggestions or speculations welcome. Thanks Wade Pearce Wedge Tail Eagles Australasian Net Gaming Association (http://wtecommand.com) "Powered by Zope"