From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Locking files for CLASH_DETECTION now supported on MS-Windows Date: Mon, 25 Feb 2013 21:46:21 -0800 Organization: UCLA Computer Science Department Message-ID: <512C4C2D.8050704@cs.ucla.edu> References: <83wqtwi90o.fsf@gnu.org> <512BA7F6.4010304@cs.ucla.edu> <83txp0i6cy.fsf@gnu.org> <512BB3C1.40201@cs.ucla.edu> <83ehg3iv18.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1361857589 27456 80.91.229.3 (26 Feb 2013 05:46:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 26 Feb 2013 05:46:29 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 26 06:46:52 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 1UADNL-0001E4-4f for ged-emacs-devel@m.gmane.org; Tue, 26 Feb 2013 06:46:51 +0100 Original-Received: from localhost ([::1]:33409 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UADN0-0001vJ-9m for ged-emacs-devel@m.gmane.org; Tue, 26 Feb 2013 00:46:30 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:47133) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UADMx-0001v7-JH for emacs-devel@gnu.org; Tue, 26 Feb 2013 00:46:28 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UADMw-0005st-0d for emacs-devel@gnu.org; Tue, 26 Feb 2013 00:46:27 -0500 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:36366) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UADMt-0005rH-Tm; Tue, 26 Feb 2013 00:46:24 -0500 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id C3E5B39E8105; Mon, 25 Feb 2013 21:46:22 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Original-Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBl08dKvRu4s; Mon, 25 Feb 2013 21:46:22 -0800 (PST) Original-Received: from [192.168.1.9] (pool-71-189-154-249.lsanca.fios.verizon.net [71.189.154.249]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 2767D39E8100; Mon, 25 Feb 2013 21:46:22 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 In-Reply-To: <83ehg3iv18.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 131.179.128.62 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:157376 Archived-At: >> 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 and . 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.