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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 25 Feb 2013 10:56:01 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
> 
> 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.

No, I think Emacs running on a Posix host will ignore the Windows lock
file (because it's a regular file) and lock the file itself with a
different file name .#FOO.0.  So on Posix host, the file will be
locked, as it is now.

> Two thoughts.  First, how about if the MS-Windows code
> tries to use a symbolic link, and if this works then great,
> otherwise it falls back on a regular file.  That way,
> MS-Windows users who have the Create Symbolic Links right
> will interoperate better with POSIXish Emacs.

Unfortunately, most Windows users who have this privilege are also
members of the Administrators group, so Windows still pops up the UAC
elevation dialog for them.  It is entirely non-trivial to set Windows
up so that these prompts are avoided.  I don't want to rely on users
to do that.  We will get gobs of complaints that way.

> (Perhaps
> the MS-Windows code can try to directly determine whether
> it has the Create Symbolic Links right; or perhaps it can
> just try 'symlink' and inspect the resulting errno.)

The problem is that the error is returned _after_ prompting.

> Second, even if an MS-Windows user doesn't have a Create Symbolic
> Links right, Emacs should still respect a symlink that happens
> to be there, right?

If NFS reflects symlinks to Windows, then yes.  But I need someone
with good access to NFS from Windows to test such code (I don't have
such access myself).  ANd it will only work on latest versions of
Windows; Windows XP and older doesn't have the support for accessing
symlinks, so 'readlink' implemented on w32.c won't work there (it will
report that a file isn't a symlink).