From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Locking files for CLASH_DETECTION now supported on MS-Windows Date: Tue, 26 Feb 2013 20:02:53 +0200 Message-ID: <83621fhs1e.fsf@gnu.org> References: <83wqtwi90o.fsf@gnu.org> <512BA7F6.4010304@cs.ucla.edu> <83txp0i6cy.fsf@gnu.org> <512BB3C1.40201@cs.ucla.edu> <83ehg3iv18.fsf@gnu.org> <512C4C2D.8050704@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1361901791 2884 80.91.229.3 (26 Feb 2013 18:03:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 26 Feb 2013 18:03:11 +0000 (UTC) Cc: emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 26 19:03:33 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UAOsB-0007pM-P1 for ged-emacs-devel@m.gmane.org; Tue, 26 Feb 2013 19:03:27 +0100 Original-Received: from localhost ([::1]:58243 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UAOrq-0005QH-Rl for ged-emacs-devel@m.gmane.org; Tue, 26 Feb 2013 13:03:06 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:56941) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UAOro-0005Q8-B9 for emacs-devel@gnu.org; Tue, 26 Feb 2013 13:03:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UAOrj-0008U9-6j for emacs-devel@gnu.org; Tue, 26 Feb 2013 13:03:04 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:38046) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UAOri-0008Si-VD for emacs-devel@gnu.org; Tue, 26 Feb 2013 13:02:59 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MIU00600A089T00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Tue, 26 Feb 2013 20:02:57 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MIU006NAA4W0260@a-mtaout20.012.net.il>; Tue, 26 Feb 2013 20:02:57 +0200 (IST) In-reply-to: <512C4C2D.8050704@cs.ucla.edu> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:157393 Archived-At: > Date: Mon, 25 Feb 2013 21:46:21 -0800 > From: Paul Eggert > CC: emacs-devel@gnu.org > > >> (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 > and . 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.