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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 26 Feb 2013 14:19:52 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> Attached is an updated version of the patch, which avoids
> several of the problems mentioned, by using a different lock file name
> on MS-Windows.  Non-MS-Windows uses .#FILE symlinks as before;
> MS-Windows uses .#-FILE regular files.  This avoids clashes
> between the two approaches.  It also means MS-Windows ignores
> non-MS-Windows locks and vice versa, but given all the
> inherent incompatibilities involved this may be the best that
> we can do reliably.

I think I found a better solution (committed as trunk revision
111888).  Instead of using 'emacs_open', which just calls 'open', I
now use '_sopen', which allows to specify sharing restrictions for
accessing the same file via other file descriptors, both by the same
Emacs which is creating the lock file, and by other processes.  The
sharing flag I used denies any kind of access to the same file until
the file descriptor returned by _sopen is closed.  This makes the
whole open/write/close sequence in create_lock_file atomic, as far as
other potential readers or writers of the file are concerned -- they
will not be able to access the file until its contents is ready.

I tested this with one NFS-mounted volume that can be accessed from
both Windows and a GNU/Linux box.  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.  This is IMO better than ignoring the locks from the other
platform, because the latter means each Emacs thinks it has an
exclusive lock on the file, while in fact there are several lockers.

I can make a similar change in read_lock_data, but I don't think it's
needed there, since 'symlink' on Posix hosts is atomic, and thus Emacs
on Windows will always either see the symlink in its final state or
not at all.

So I think with this change, there's no longer a need to use different
file names for the lock files on Windows and on Posix hosts.