in CMSimple_XH 1.6 a minimal file locking based on flock() was finally implemented. As already mentionend in this thread, flock() might not work reliably on multithreaded IIS. In a French thead it turned out, that some providers forbid this function (in this case, the file locking causes include() to fail, what is a regression in CMSimple_XH 1.6, as earlier versions work fine there).
We should consider to replace our current simple flock() with a more sophisticated solution, that offers some kind of fallback for servers where flock() doesn't work as expected. As I see no possibility to detect whether flock() works properly, so we may have to introduce a new (hidden) configuration option, so the user is able to control the behavior.
A very simple solution would be to eschew the file locking when configured respectively:
Code: Select all
/**
* Locks or unlocks an opened file and returns whether that succeeded.
*
* Can be disabled with $cf['files']['lock].
*
* @param resource $handle A file handle.
* @param int $operation A lock operation constant.
*
* @return bool
*
* @global array The configuration of the core.
*
* @see flock()
*
* @since 1.6.3
*/
function XH_flock($handle, $operation)
{
global $cf;
if ($cf['files']['lock']) {
return flock($handle, $operation);
} else {
return true;
}
}
Please note, that this issue is not directly related to my suggestion about Request-spanning file locking and should be handled and voted upon indepently.
Finally, I want to stress that these kinds of file locking are purely advisory, i.e. they only can work properly, if everybody heeds the locks. So plugins that read/write configuration and languages files directly (not via the plugin loader), should implement file locking, what can be easily accomplished by using XH_includeVar() resp. XH_writeFile(). For working with content.htm there are XH_readContents() and XH_saveContents().
Christoph