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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 02 Mar 2013 12:43:05 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: 13807@debbugs.gnu.org
> 
> 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.

That's not what happened in my testing.  There, there was no lock file
named .#FILE.0 or anything like that.  Can you describe your testing
in more details, and what versions of NFS and Windows did you use?

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

That's a different issue, though.

> 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 wish you didn't install the .#-FILE part.  It is no longer
justified.