bug#13807: updated version to avoid MS-Windows vs non-MS-Windows clashes

[Paul Eggert <eggert@cs.ucla.edu>]

On 02/27/2013 10:49 AM, Eli Zaretskii wrote:

> The results were that when Emacs running on GNU/Linux had the file
> locked, Emacs running on Windows would refrain from locking it, and
> vice versa when the file was locked by Emacs running on Windows and
> a GNU/Linux Emacs would try to lock it.

Unfortunately when (for example) the GNU/Linux Emacs refrained from
locking the file, what it was actually doing was using its own
separate lock file, whose name it got in a buggy way.  That is, when
locking FILE it discovered a regular file .#FILE (the MS-Windows lock
file) and then decided to use a symlink .#FILE.0, thus ignoring the
MS-Windows lock.

The process of guessing a lock file name by appending ".0" is
obviously flaky, as it's prone to races.  The recent MS-Windows
changes have made the races more likely, but they were present even
before the changes.  Emacs should not guess the lock file name.

For now, I've installed the patch as trunk bzr 111918, as it fixes these
races.  This patch causes Emacs to use a different lock file name
.#-FILE for MS-Windows than the usual lock file .#FILE for GNU/Linux,
which is not good, but Emacs was using different lock files anyway,
and a virtue of the patch is that any problems in the MS/Windows
implementation won't get in the way of GNU/Linux users on a networked
file system.

I will look into adjusting Emacs so that it uses the same lock file
name .#FILE for both GNU/Linux and MS-Windows, which would be nicer
than the patched Emacs.  This will take some more thought, though.