bug

[ikiwiki.git] / doc / bugs / ikiwiki_cgi_fails_to_build_on_Solaris_due_to_missing_LOCK__95__EX.mdwn

diff --git a/doc/bugs/ikiwiki_cgi_fails_to_build_on_Solaris_due_to_missing_LOCK__95__EX.mdwn b/doc/bugs/ikiwiki_cgi_fails_to_build_on_Solaris_due_to_missing_LOCK__95__EX.mdwn
index 6286d6893056bf1879e8ef266b6b17b115518e28..aca1ef106e9f65addb1e9175a6b2ea9113764c43 100644 (file)
--- a/doc/bugs/ikiwiki_cgi_fails_to_build_on_Solaris_due_to_missing_LOCK__95__EX.mdwn
+++ b/doc/bugs/ikiwiki_cgi_fails_to_build_on_Solaris_due_to_missing_LOCK__95__EX.mdwn
@@ -13,3 +13,31 @@ cc: Sun C 5.9 SunOS_i386 Patch 124868-01 2007/07/12
 
 
 I don't know enough C to provide a patch, but from googling it, people seem to be suggesting fcntl has an alternative.
+
+
+-----
+
+
+changing
+
+    if (lockfd != -1 && flock(lockfd, LOCK_EX) == 0) {
+   
+
+to read
+
+    if (lockfd != -1 && lockf(lockfd, F_LOCK,0) == 0) {
+
+
+in IkiWiki/Wrapper.pm  lets it compile, according to
+http://man-wiki.net/index.php/3:lockf "On  Linux, this call is just an
+interface for fcntl(2)"  does this seem like a sensible fix?a
+
+> Don't see why not. flock was used only because it's being used
+> in the same file for testing some other locks.
+> 
+> While lockf's fcntl locks are not inherited across a fork,
+> that doesn't matter for this lock, which is only used to
+> prevent more than one ikiwiki perl process being run at a time.
+> Nor is there any need to be compatible with some other user of this
+> lock; it's only checked in one place. [[applied|done]]
+> --[[Joey]]