Last modified: 2010-05-15 15:29:01 UTC
User A starts an edit on a page, user B then starts a second edit. If user A commits the edit, that change will be visible until user B commits his edit, at which point the page becomes blank (although history is available), instead of displaying the edit conflict screen. This is 100% reproduceable (please feel free to use the Sandbox: http://wiki.cs.princeton.edu/index.php/Sandbox). System components: Apache 1.3.31 (running on a recently-patched Solaris9 system), PHP 4.3.9, MySQL 4.0.18 (also running on Solaris9) The problem does NOT occur when installing the software (v1.3.4) on a Linux server (this was tested on two different Linux machines, one using the same database server as above). Other conditions: * Client access from 3 different machines (Linux, Mac and Windows) * Browsers used: Firefox, Mozilla, Netscape, IE, Safari * Combinations of logged-in and anonymous users used to edit test pages
This could be a problem with "diff3", used by the conflict merging code. Being an external program, this is good candidate for varying by OS. Could you try setting $wgDiff3=''; in your LocalSettings.php, and seeing if that makes a difference: it should fall back to giving an edit conflict screen every time. My guess is the Solaris diff3 takes different command line paramaters, so isn't behaving as MediaWiki expects.
(In reply to comment #1) > This could be a problem with "diff3", used by the conflict merging code. Being > an external program, this is good candidate for varying by OS. Could you try > setting $wgDiff3=''; in your LocalSettings.php, and seeing if that makes a > difference: it should fall back to giving an edit conflict screen every time. > > My guess is the Solaris diff3 takes different command line paramaters, so isn't > behaving as MediaWiki expects. Setting $wgDiff3 solved the problem, both for the NULL value, and (as I happened to have it) pointing it to the GNU version of diff3. The Solaris diff3 is sufficiently different from the GNU version to cause things to fail. I'm not resolving the bug, in hopes that the install process could be modified to detect (or not, as the case may be) the GNU diff3.
(In reply to comment #2) > I'm not resolving the bug, in hopes that the install process could be modified > to detect > (or not, as the case may be) the GNU diff3. Well, it looks like there isn't much chance of getting a compatible result out of the Solaris diff3: from the look of its man page at http://docs.sun.com/db/doc/816-0210/6m6nb7m7g?a=view it will only ever output ed scripts, not the diffs and merges that we want. As for checking if the detected binary is the GNU version, we should be able to execute "{$wgDiff3} --version" and see if the output begins "diff3 (GNU diffutils)"; perhaps, as suggested, the installer could seek out an instance of 'diff3', and only set $wgDiff3 in the install if it is the GNU version. If it exists but is wrong, a message could be displayed on the installation screen explaining this.
changed severity to normal as workaround has been provided
Probably many systems have both gnu diff3 and vendor diff3 in the path, so it might be useful to not just test diff3, but if it fails, look for another one.
This bug also happens on AIX 5.1, and probably other AIX versions.
fixed for the Solaris case in 1.5, will be in 1.5beta2. testing for AIX and other systems would be nice.
