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

[Eli Zaretskii]

> Date: Mon, 25 Feb 2013 10:56:01 -0800
> From: Paul Eggert <address@hidden>
> CC: address@hidden
> 
> On 02/25/13 10:41, Eli Zaretskii wrote:
> > If MS-Windows creates the lock file first, then the Posix host will
> > see that it's a regular file and skip it.
> 
> Yes, that's one worrisome scenario -- if an MS-Windows
> Emacs locks a file, POSIXish Emacs instances will ignore
> the locks and won't be able to set locks themselves.

We could avoid this by teaching Emacs on Posix systems to read lock
files created by Emacs running on Windows.  All this takes is losing
the #ifdef's in read_lock_data, the code there is general and not
Windows specific in any way.  We could also strengthen this by
considering a file locked just because the .#FOO lockfile exists, even
if we cannot read that file or decipher its contents -- this would
avoid losing due to some race conditions.  We could, e.g., tell the
Posix user that the file "appears to be locked by an unknown remote
user" or some such, if we cannot parse the lock information.

Another possibility would be to make Emacs running on Windows avoid
locking files on remote filesystems.  AFAIU, failure to lock a file is
silently ignored.  This method has a disadvantage of including in the
ban networked volumes run by Windows servers, where locking could be
enabled, but I think there are APIs which will allow to discern
between the two.  And even if we cannot distinguish between them, the
situation won't be worse than in previous versions of Emacs on
Windows.

> For example, assuming current trunk (bzr 111882), suppose MS-Windows
> host A creates a regular file '.#FOO', and GNU/POSIX host B creates a
> symbolic link '.#FOO.0'.  They both think they own the lock for FOO,
> which is bad but no worse than Emacs 24.3.  But suppose that A then
> releases its lock and GNU/POSIX host C then locks the file with a
> symbolic link '.#FOO'.  At this point B and C both think they own the
> lock, which is a regression from Emacs 24.3.  The bug exists because
> of A's intervention and because of the new MS-Windows behavior.

This scenario would be solved by any of the two possible solutions
mentioned above, I think.

Are there any other scenarios we should consider?