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:17:16 +0200 Message-ID: <834ngzhrdf.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 1361902656 11951 80.91.229.3 (26 Feb 2013 18:17:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 26 Feb 2013 18:17:36 +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:17:57 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 1UAP6B-0006LH-Op for ged-emacs-devel@m.gmane.org; Tue, 26 Feb 2013 19:17:55 +0100 Original-Received: from localhost ([::1]:40326 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UAP5q-0004pV-Tu for ged-emacs-devel@m.gmane.org; Tue, 26 Feb 2013 13:17:34 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:35936) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UAP5h-0004oR-Ff for emacs-devel@gnu.org; Tue, 26 Feb 2013 13:17:33 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UAP5e-0005kQ-Ve for emacs-devel@gnu.org; Tue, 26 Feb 2013 13:17:25 -0500 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:34790) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UAP5e-0005jx-89 for emacs-devel@gnu.org; Tue, 26 Feb 2013 13:17:22 -0500 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MIU00900ALCK600@a-mtaout21.012.net.il> for emacs-devel@gnu.org; Tue, 26 Feb 2013 20:17:20 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MIU009IDASVI150@a-mtaout21.012.net.il>; Tue, 26 Feb 2013 20:17:20 +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:157395 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. We could avoid this by teaching Emacs on Posix systems to read lock files created by Emacs running on Windows. All this takes is losing the #ifdef's in read_lock_data, the code there is general and not Windows specific in any way. We could also strengthen this by considering a file locked just because the .#FOO lockfile exists, even if we cannot read that file or decipher its contents -- this would avoid losing due to some race conditions. We could, e.g., tell the Posix user that the file "appears to be locked by an unknown remote user" or some such, if we cannot parse the lock information. Another possibility would be to make Emacs running on Windows avoid locking files on remote filesystems. AFAIU, failure to lock a file is silently ignored. This method has a disadvantage of including in the ban networked volumes run by Windows servers, where locking could be enabled, but I think there are APIs which will allow to discern between the two. And even if we cannot distinguish between them, the situation won't be worse than in previous versions of Emacs on Windows. > 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. This scenario would be solved by any of the two possible solutions mentioned above, I think. Are there any other scenarios we should consider?