Page MenuHomePhabricator

Sun's diff3 makes concurrent edits produce a blank page instead of edit-conflict
Closed, ResolvedPublic

Description

Author: elgersma

Description:
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

Version: 1.3.x
Severity: normal
URL: http://wiki.cs.princeton.edu/

Details

Reference
bz619

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 7:07 PM
bzimport set Reference to bz619.
bzimport added a subscriber: Unknown Object (MLST).

rowan.collins wrote:

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.

elgersma wrote:

(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.

rowan.collins wrote:

(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.

mediazilla wrote:

changed severity to normal as workaround has been provided

ssd.moz wrote:

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.

mork.the.delayer wrote:

This bug also happens on AIX 5.1, and probably other AIX versions.

river wrote:

fixed for the Solaris case in 1.5, will be in 1.5beta2. testing for AIX
and other systems would be nice.