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: Tue, 26 Feb 2013 14:34:29 -0800 Message-ID: <512D3875.5020307@cs.ucla.edu> References: <83wqtwi90o.fsf@gnu.org> <512BA7F6.4010304@cs.ucla.edu> <83txp0i6cy.fsf@gnu.org> <512BB3C1.40201@cs.ucla.edu> <834ngzhrdf.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 1361919248 15597 80.91.229.3 (26 Feb 2013 22:54:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 26 Feb 2013 22:54:08 +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 23:54:31 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 1UATPq-0007DF-5Y for ged-emacs-devel@m.gmane.org; Tue, 26 Feb 2013 23:54:30 +0100 Original-Received: from localhost ([::1]:37536 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UATPV-00054G-Ch for ged-emacs-devel@m.gmane.org; Tue, 26 Feb 2013 17:54:09 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:34972) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UATPS-000541-No for emacs-devel@gnu.org; Tue, 26 Feb 2013 17:54:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UAT6Y-000707-J8 for emacs-devel@gnu.org; Tue, 26 Feb 2013 17:34:36 -0500 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:54052) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UAT6V-0006zS-Tn; Tue, 26 Feb 2013 17:34:32 -0500 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id E47F139E8106; Tue, 26 Feb 2013 14:34:30 -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 l1Hm7EGpOeIS; Tue, 26 Feb 2013 14:34:30 -0800 (PST) Original-Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 2B2C739E8008; Tue, 26 Feb 2013 14:34:30 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130219 Thunderbird/17.0.3 In-Reply-To: <834ngzhrdf.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:157410 Archived-At: On 02/26/13 10:17, Eli Zaretskii wrote: > We could avoid this by teaching Emacs on Posix systems to > read lock files created by Emacs running on Windows. I don't see how to do this without introducing race conditions that are not present in the current GNU/Linux implementation. There are atomic system calls to create, test, and remove symbolic links, but the corresponding syscalls do not exist directly for regular files, and would need to be implemented carefully. Doing this portably and reliably, in a way where the MS-Windows and non-MS-Windows approaches work together, will take some work. > We could also strengthen this by considering a file locked > just because the .#FOO lockfile exists Other applications (i.e., not GNU Emacs) create regular files .#FOO, and Emacs shouldn't be impeded from editing FOO merely because some other application has created .#FOO. (We could try to parse .#FOO but this leads to races.) > Another possibility would be to make Emacs running on Windows avoid > locking files on remote filesystems. Won't there still be a problem if the local file system is exported? MS-Windows Emacs will use Windows-style locking on the local file system, and this might confuse non-MS-Windows Emacs accessing the same file. > Are there any other scenarios we should consider? To move things forward, I propose that the MS-Windows implementation use a different lock file name .#-FOO. (The '-' is because '-' is not commonly used as the first character of a file name.) MS-Windows and non-MS-Windows instances will ignore each others' locks. This avoids the race conditions mentioned earlier, and it will mean that MS-Windows instances won't mess up non-MS-Windows instances. It has the downside that MS-Windows and non-MS-Windows instances will ignore each others' locks, but that's better than where we are now. If we can come up with a reliable scheme whereby MS-Windows and non-MS-Windows Emacs versions can both use the same lock file name, we can unify the two approaches, but for now using different names is a simple fix that should make GNU/Linux Emacs locking reliable again. A patch to implement this proposal is in .