I experienced the "setup mysteriously deletes itself" bug [1] today, even
after I'd set up a single cron script [2] that was a suggested fix.
I dug into the problem a little, which apparently is a result of more than
one instance download_emails.php stepping on the other in the midst of
performing Setup::Save().
I looked at the PHP manual for flock() [3], which states:
Note: Because flock() requires a file pointer, you may have to use
a special lock file to protect access to a file that you intend to
truncate by opening it in write mode (with a "w" or "w+" argument to
fopen()).
Since that is exactly what class.setup.php is doing, perhaps a "special"
lock file needs to exist in /path-to-eventum/misc that acts as the
gatekeeper lockfile for setup.config.php.
Proposed fix:
Instead of ....
$fp = @fopen(APP_SETUP_FILE, "w");
if (!$fp) {
return -2;
}
@flock($fp, LOCK_EX);
@fwrite($fp, base64_encode(serialize($options)));
@fclose($fp);
@flock($fp, LOCK_UN);
return 1;
.... How about:
// Get a good lock
$sfp = @fopen(APP_SETUP_LOCK_FILE, 'a');
if (!$sfp) {
return -2;
}
@flock($sfp, LOCK_EX);
// Truncate and write setup
$fp = @fopen(APP_SETUP_FILE, "w");
if (!$fp) {
return -2;
}
// be on the safe side
@flock($fp, LOCK_EX);
@fwrite($fp, base64_encode(serialize($options)));
@flock($fp, LOCK_UN);
@fclose($fp);
@fwrite($sfp, '.');
@flock($sfp, LOCK_UN);
@fclose($sfp);
return 1;
This fix addresses another potential problem -- currently, class.setup.php
closes the APP_SETUP_FILE before it releases the lock. This is a no-no, by
my understanding, as well as by the example of flock() usage in the manual.
What do you guys think?
-Clay
[1] http://lists.mysql.com/eventum-users/166
[2] http://lists.mysql.com/eventum-users/169
[3] http://www.php.net/manual/en/function.flock.php
--
Killersoft.com
