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 06:00:35 +0200 Message-ID: <83ehg3iv18.fsf@gnu.org> References: <83wqtwi90o.fsf@gnu.org> <512BA7F6.4010304@cs.ucla.edu> <83txp0i6cy.fsf@gnu.org> <512BB3C1.40201@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1361851245 11739 80.91.229.3 (26 Feb 2013 04:00:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 26 Feb 2013 04:00:45 +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 05:01:08 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 1UABj2-0001LN-1R for ged-emacs-devel@m.gmane.org; Tue, 26 Feb 2013 05:01:08 +0100 Original-Received: from localhost ([::1]:45939 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UABih-0007qa-3S for ged-emacs-devel@m.gmane.org; Mon, 25 Feb 2013 23:00:47 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:41119) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UABie-0007pZ-TM for emacs-devel@gnu.org; Mon, 25 Feb 2013 23:00:45 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UABic-00027X-F9 for emacs-devel@gnu.org; Mon, 25 Feb 2013 23:00:44 -0500 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:41149) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UABic-00027O-61 for emacs-devel@gnu.org; Mon, 25 Feb 2013 23:00:42 -0500 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MIT004006X52N00@a-mtaout21.012.net.il> for emacs-devel@gnu.org; Tue, 26 Feb 2013 06:00:40 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MIT004SB7542E10@a-mtaout21.012.net.il>; Tue, 26 Feb 2013 06:00:40 +0200 (IST) In-reply-to: <512BB3C1.40201@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.169 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:157371 Archived-At: > Date: Mon, 25 Feb 2013 10:56:01 -0800 > From: Paul Eggert > 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).