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

[Paul Eggert]

>> 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.

Sorry, I should have been clearer.  My comment was assuming the
patch in Bug#13807, which simplifies the analysis.  In the
current Emacs the races are different and the analysis trickier,
but the bugs are still there.

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.

There are other races like that.  The Bug#13807 patch fixes the races
for GNU/POSIX hosts.  But there are still races if MS-Windows hosts are
involved.

>> (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.

OK, then how about just checking whether the privilege is present?
That shouldn't cause a prompt.  For example, Emacs might invoke
OpenProcessToken and GetTokenInformation to see whether the current
process has SeCreateSymbolicLinkPrivilege.  Or it could do something
simpler and slower, e.g., run the equivalent of system ("WHOAMI /PRIV
| grep 'SeCreateSymbolicLinkPrivilege.*Enabled'") (pardon my lack of
MS-Windows coding skills, but I hope you get the idea).

>> 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.

Apparently it does, but the symlinks appear to be regular files (!).
See <http://technet.microsoft.com/en-us/library/hh310285%28v=ws.10%29.aspx>
and <http://msdn.microsoft.com/en-us/library/ee380665.aspx>.

This whole area is messy, alas.

How about this idea?  It should be an improvement:
the MS-Windows port could use symbolic links a la the patch in Bug#13807
if SeCreateSymbolicLinkPrivilege is present, and fall back
on the 24.3 behavior if SeCreateSymbolicLinkPrivilege is absent.