Re: Locking files for CLASH_DETECTION now supported on MS-Windows

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

On 02/26/13 10:17, Eli Zaretskii wrote:

> We could avoid this by teaching Emacs on Posix systems to
> read lock files created by Emacs running on Windows.

I don't see how to do this without introducing race
conditions that are not present in the current GNU/Linux
implementation.  There are atomic system calls to create,
test, and remove symbolic links, but the corresponding
syscalls do not exist directly for regular files, and would
need to be implemented carefully.  Doing this portably and
reliably, in a way where the MS-Windows and non-MS-Windows
approaches work together, will take some work.

> We could also strengthen this by considering a file locked
> just because the .#FOO lockfile exists

Other applications (i.e., not GNU Emacs) create regular
files .#FOO, and Emacs shouldn't be impeded from editing FOO
merely because some other application has created .#FOO.  (We
could try to parse .#FOO but this leads to races.)

> Another possibility would be to make Emacs running on Windows avoid
> locking files on remote filesystems.

Won't there still be a problem if the local file system is
exported?  MS-Windows Emacs will use Windows-style locking
on the local file system, and this might confuse
non-MS-Windows Emacs accessing the same file.

> Are there any other scenarios we should consider?

To move things forward, I propose that the MS-Windows
implementation use a different lock file name .#-FOO.  (The
'-' is because '-' is not commonly used as the first
character of a file name.)  MS-Windows and non-MS-Windows
instances will ignore each others' locks.  This avoids the
race conditions mentioned earlier, and it will mean
that MS-Windows instances won't mess up non-MS-Windows
instances.  It has the downside that MS-Windows and
non-MS-Windows instances will ignore each others' locks,
but that's better than where we are now.

If we can come up with a reliable scheme whereby MS-Windows
and non-MS-Windows Emacs versions can both use the same lock
file name, we can unify the two approaches, but for now
using different names is a simple fix that should make
GNU/Linux Emacs locking reliable again.

A patch to implement this proposal is in
<http://bugs.gnu.org/13807#14>.