-
2008-05-03
geby
I have perfectly working Dokuwiki 2007-06-26. I try to upgrade it to latest RC version. All working fine, except one:
After a few changes on various wiki pages, global 'recent changes' page showing bad informations. Some pages are missing, others showing date 1970, etc.
I found, file _dokuwiki.changes is corrupted, contains lot of zero bytes inside in the middle. I try to delete this file at all, but after a few wiki changes new file is corrupted again by exactly same way. Changelog file for separate each page are OK.
It is mysterious for me, because page changelog and global changelog is written on same place by same routine from same variable. :-O
When I downgrade back to version 2007-06-26, problem are gone and all is fine now.
My system info:
os Linux
webserver Apache/2.0.63 (Unix) mod_ssl/2.0.63 OpenSSL/0.9.8g PHP/4.4.8 mod_ddmh/0.0.14
-
2008-05-24
geby
After a some time it happen with old version too. :-(
I try to change to different server with different PHP (was PHP4, now PHP5) and problem persist.
-
2008-05-29
geby
problem persist on latest Dokuwiki version too.
I made a little workaround, added Trim to parseChangelogLine function, for ignoring changelog file corruption:
function parseChangelogLine($line) {
$line = trim($line, "\x00"); //workaround for corrupted changelogs (Geby)
$tmp = explode("\t", $line);
if ($tmp!==false && count($tmp)>1) {
$info = array();
$info['date'] = (int)$tmp[0]; // unix timestamp
$info['ip'] = $tmp[1]; // IPv4 address (127.0.0.1)
$info['type'] = $tmp[2]; // log line type
$info['id'] = $tmp[3]; // page id
$info['user'] = $tmp[4]; // user name
$info['sum'] = $tmp[5]; // edit summary (or action reason)
$info['extra'] = rtrim($tmp[6], "\n"); // extra data (varies by line type)
return $info;
} else { return false; }
}
-
2008-07-08
geby
After some time I see other file corruptions too. (some in page cache, or file with poll,...)
I read the sources and I found a problem. File writes are protected by locks. It is good! But file write operation is not atomic, and during pending write operation file can be readed by concurrent connection. This can read mangled content... modify it and write it back. And file is corrupted!
As quick fix ad add call io_lock and io_unlock to io_readFile and i waiting, if it solve my problems. Yes, this slowdown performance, besty will be change write strategy instead. (Write new file to temp file and then do atomic file rename...)
-
2008-08-29
geby
Well, non-atomic file append is finally source of all my problems.
Finally fix is add true system Lock call to write routine. Reading must not be protected by locks, but writes yes.
On many systems is appending to file atomic... but on some systems not!
Now is all OK here.
-
2008-10-11
andi
io_saveFile already contains a locking mechanism. Could it happen that a write operation on your system takes more than 3 seconds? Are you using the safemodehack? Can you please post the code changes you did?
-
2008-10-11
geby
I just added one flock call to io_savefile routine end:
flock($fh, LOCK_EX);
fwrite($fh, $content);
fclose($fh);
Yes, I know, you have your own locking system, but it protecting concurrent writes only. But what happen when file is readed during write operation? Your system assuming atomic write operation on file opened in 'append' mode. This is true for standard PHP, but it is not true on some special PHP implementations. (I am using hosting, what not using safemode at all, but it have their own file operation hacks instead, for example.)
BTW: my write operations are very fast, it is not a problem with timeouted locks!
My added flock call definitively fix all my problems, Dokuwiki still working very fine after my fix!
-
2010-06-26
andi
closing since this seems to be related to this special system setup only.