Well, I see that 1.1.6 is now out, and that the developers have chosen not to address this critical problem. I say "critical" because not a day goes by that some frantic SMF owner isn't posting here or on my hosting service's boards that certain things aren't defined. It is because their Settings.php has been wiped out by a database error, and all this suffering (and bad press for SMF) is unnecessary. Earlier I posted a fix for it, and there's probably an even easier fix.
Settings.php gets rewritten (updateSettingsFile() in Admin.php) with a new "last error" timestamp code whenever a database error is discovered. The problem is the way this is done: during the process, due to one particular server's problem, the author chose to empty out the Settings file (after reading in and storing its contents). It's done by opening for writing, and immediately closing the file. Then the revised contents are written to the (now empty) file.
If you have two members running the forum at the same time, and they both experience a database error within a very short time (not an uncommon event), it appears to me that this could cause the problem. Member 1 gets an error and runs updateSettingsFile(). It reads in Settings.php's contents, and then empties out Settings.php. At this moment, Member 2 is also running updateSettingsFile() in response to a database error (if Member 1 just experienced an error, it should be common for Member 2 to also). If the timing of events is just wrong, Member 2 reads the contents of Settings.php -- which at this moment is empty -- and the check for good content (see comment "Make sure we got a good file.") does not result in an early exit. Member 1 rewrites Settings.php with a revised content, and a moment later, Member 2 empties out the file and rewrites it with EMPTY content. From that moment on, all SMF users are screwed.
Can anyone tell me if this is the correct analysis? It sure looks like it's happening, and it would be good to fix it once and for all. My earlier suggested fix involved moving the vulnerable part to a separate included file, so only one line gets wiped out at worst (and can be "repaired" easily). If that is not satisfactory, updateSettingsFile() should somehow lock Settings.php so a Member running SMF can't try reading it while another Member is emptying it out and rewriting it. Another method would be to improve the code that tries to detect whether an empty Settings.php was read in. My guess is that it's not working in all cases. The check for $settingsArray having fewer than 12 elements ought to do the job, but I suspect it's not. Could someone please take a look at the 1.1.6 code and see if there's any way one could get through the checks after reading an empty Settings.php file, and still be allowed to rewrite it?
Unfortunately, without a way to repeatably kick off updateSettingsFile() at just the right interval, it may never be possible to prove that my theory is correct. However, from the number of reports of Settings.php files being wiped out, something is going on!