emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: Re: Locking files for CLASH_DETECTION now supported on MS-Windows
Date: Tue, 26 Feb 2013 20:02:53 +0200

> Date: Mon, 25 Feb 2013 21:46:21 -0800
> From: Paul Eggert <address@hidden>
> CC: address@hidden
> 
> >> (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 doesn't help, because according to my testing, the privilege is
normally not originally present in the process token, even if the user
can acquire that privilege.  (The w32 'symlink' implementation tries
to acquire the privilege if the attempt to create a symlink without
doing that fails.)

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

Yes, my testing on one particular NFS-mounted volume confirms this:
Emacs on Windows sees Unix-side symlinks as regular files.  Reading
them yields some magic signature, followed by something that looks
like the target of the symlink encoded in UTF-16.  Is this the
universally accepted way of writing a symlink?

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

See above.  It would be easy to allow the w32 Emacs try 'readlink'
first, and only fall back on reading the file if that fails, though.
That way, if some remote filesystem does support symlinks, at least
part of the problems with Windows/Unix interoperability will be
avoided.

In any case, since Windows support for symlinks across NFS mounts is
very incomplete, to say the least, using symlinks does not seem to be
a reliable way of avoiding potential problems to Emacs running on
Posix hosts by Emacs running on Windows.  So I suggest we look into
alternative solutions for these problems.  I will write about that in
a separate message.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]