aboutsummaryrefslogtreecommitdiff
path: root/IkiWiki/CGI.pm
diff options
context:
space:
mode:
authorjoey <joey@0fa5a96a-9a0e-0410-b3b2-a0fd24251071>2007-10-10 18:40:54 +0000
committerjoey <joey@0fa5a96a-9a0e-0410-b3b2-a0fd24251071>2007-10-10 18:40:54 +0000
commit278b16c79ad98514e19dd3301e771516499f7a24 (patch)
tree96cc329eef2585f5a5feaff6e246f35b10f965dc /IkiWiki/CGI.pm
parent66a137848f0310b8721fbd276581890e26ecfbb4 (diff)
downloadikiwiki-278b16c79ad98514e19dd3301e771516499f7a24.tar
ikiwiki-278b16c79ad98514e19dd3301e771516499f7a24.tar.gz
* In the cgi edit path, reload the index file before rendering. A bug
showed up where a web edit that added a page caused a near-concurrent web edit to fail in will_render. While it would be hard to reproduce this, my analysis is that the failing cgi started first, loaded the index file (prior to locking) then the other cgi created the new page and rendered it, and then the failing cgi choked on the new file when _it_ tried to render it. Ensuring that the index file is loaded after taking the lock will avoid this bug.
Diffstat (limited to 'IkiWiki/CGI.pm')
-rw-r--r--IkiWiki/CGI.pm4
1 files changed, 4 insertions, 0 deletions
diff --git a/IkiWiki/CGI.pm b/IkiWiki/CGI.pm
index 155010a97..788d0487e 100644
--- a/IkiWiki/CGI.pm
+++ b/IkiWiki/CGI.pm
@@ -596,6 +596,10 @@ sub cgi_editpage ($$) { #{{{
# may have been committed while the post-commit hook was
# disabled.
require IkiWiki::Render;
+ # Reload index, since the first time it's loaded is before
+ # the wiki is locked, and things may have changed in the
+ # meantime.
+ loadindex();
refresh();
saveindex();