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

[Eli Zaretskii]

> Date: Tue, 26 Feb 2013 14:34:29 -0800
> From: Paul Eggert <address@hidden>
> CC: address@hidden
> 
> 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.

I just installed a changeset which makes the open/write/close sequence
in create_lock_file atomic wrt other processes that access the same
lock file.  My testing indicates that the lock file cannot be accessed
(read, written, renamed, or deleted) neither from Windows nor from
GNU/Linux, until the Emacs process which is writing the lock file
finishes and closes the handle.

As far as I understand the logic of lock_file, it will silently
refrain from creating a lock file if trying to do so or trying to read
the lock data fails with any error but EEXIST.  After the changes I
made, Emacs on GNU/Linux returns EACCES (theoretically, it could also
be EINVAL, but I didn't see that) if it tries to lock the same file
while Emacs on Windows is in the process of writing its lock file.  In
the reverse scenario, i.e. if a Posix host locks the file and Emacs on
Windows tries to do that later, it fails to read the file's contents
(current_lock_owner returns -1).  In both cases, the Emacs instance
that is the second one to lock the file does not lock it.  I think
this is better than letting both instances lock the same file and
think they each have an exclusive lock.