From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#13807: updated version to avoid MS-Windows vs non-MS-Windows clashes Date: Sun, 03 Mar 2013 18:39:55 +0200 Message-ID: <83ppzgtp2c.fsf@gnu.org> References: <512A98D5.7080000@cs.ucla.edu> <512D3508.1000906@cs.ucla.edu> <83txoxwq0p.fsf@gnu.org> <51326459.4030001@cs.ucla.edu> <83vc99tsbm.fsf@gnu.org> <51327F29.5000600@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1362328860 29418 80.91.229.3 (3 Mar 2013 16:41:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 3 Mar 2013 16:41:00 +0000 (UTC) Cc: 13807@debbugs.gnu.org To: Paul Eggert , Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Mar 03 17:41:20 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1UCByR-0004ou-LE for geb-bug-gnu-emacs@m.gmane.org; Sun, 03 Mar 2013 17:41:19 +0100 Original-Received: from localhost ([::1]:48015 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UCBy6-00038R-9L for geb-bug-gnu-emacs@m.gmane.org; Sun, 03 Mar 2013 11:40:58 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:58447) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UCBy2-00038K-RC for bug-gnu-emacs@gnu.org; Sun, 03 Mar 2013 11:40:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UCBy1-00013B-Dn for bug-gnu-emacs@gnu.org; Sun, 03 Mar 2013 11:40:54 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:53190) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UCBy1-000136-8W for bug-gnu-emacs@gnu.org; Sun, 03 Mar 2013 11:40:53 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UCByA-00058R-0I for bug-gnu-emacs@gnu.org; Sun, 03 Mar 2013 11:41:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 03 Mar 2013 16:41:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13807 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 13807-submit@debbugs.gnu.org id=B13807.136232882519688 (code B ref 13807); Sun, 03 Mar 2013 16:41:01 +0000 Original-Received: (at 13807) by debbugs.gnu.org; 3 Mar 2013 16:40:25 +0000 Original-Received: from localhost ([127.0.0.1]:57298 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UCBxY-00057U-Tk for submit@debbugs.gnu.org; Sun, 03 Mar 2013 11:40:25 -0500 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:60547) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UCBxW-00057G-AI for 13807@debbugs.gnu.org; Sun, 03 Mar 2013 11:40:23 -0500 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MJ300M00FKLIO00@a-mtaout21.012.net.il> for 13807@debbugs.gnu.org; Sun, 03 Mar 2013 18:40:05 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MJ300M6PFMSCR60@a-mtaout21.012.net.il>; Sun, 03 Mar 2013 18:40:05 +0200 (IST) In-reply-to: <51327F29.5000600@cs.ucla.edu> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:72048 Archived-At: > Date: Sat, 02 Mar 2013 14:37:29 -0800 > From: Paul Eggert > CC: 13807@debbugs.gnu.org > > On 03/02/2013 01:17 PM, Eli Zaretskii wrote: > > Can you describe your testing > > in more details, and what versions of NFS and Windows did you use? > > Sure, I created a MS-Windows style lock file .#FILE by hand, then > edited FILE with a GNU/Linux Emacs. But this is not a faithful reproduction of what happens when .#FILE is created by Emacs running on Windows. Because of the way Emacs on Windows creates/opens this file, it is effectively inaccessible to any other process, even _after_ the file is written and its handle closed. My testing indicates that 'readdir' does return the file's name, but every other system call I tried, including even 'lstat', fails with EPERM. (I don't know whether all NFS servers behave that way.) And that caused Emacs on GNU/Linux to refrain from locking the file. In addition, with the changes you installed, I think even if .#FILE _can_ be accessed, Emacs on a Posix host will refrain from locking it, because 'readlink' will fail for it, right? There are no more .#FILE.0 alternative names. So I still don't see the reason for using different names on Windows and Posix hosts. > There's another issue: a GNU/Linux Emacs might be using an > MS-Windows file system that does not support symbolic links. Such > an Emacs should use a regular-file lock, just as MS-Windows Emacs does, > which means that the code to create regular-file locks should be implementable > in POSIXish primitives. Also, locking should work even if the Emacs > instance that created a lock uses a symlink whereas the Emacs instance > trying to get the lock would use a regular file, or vice versa. But these issues are unrelated to the MS-Windows build of Emacs. They existed since about forever, and we never cared. Why is it suddenly so important that this feature works with 110% reliability, something it never did? Am I the only one who thinks we are way past the point of diminishing returns here1? Stefan? Anyone? > It'll take some thinking to get all this to work well. I've written > a first cut for this and have attached it. I have not tested this > on MS-Windows at all, and haven't tested it as much as I'd like on > GNU/Linux, but it should give a feel for the sort of changes that > need to be made. Unfortunately the patch is a bit complicated, > but to some extent this is inherent in such a complicated area. I think we are wasting our time and energy here. Nothing terrible will happen if locking silently fails from time to time, as it always did. If we want, we could even optionally make these failures be announced, by looking at the value lock_file returns, which we currently ignore. But if we do go in the direction you suggest, I think we will need to provide two completely separate implementations for create_lock_file, one for Posix, the other for MS-Windows. This is because the primitives you used in your suggested patch have problems on Windows: 'rename' is not atomic when it needs to delete the target (this is not supported by the MS 'rename', so we emulate this in w32.c:sys_rename), and hard links are only supported on NTFS, so editing files on FAT32 volumes (flash drives are normally formatted this way) will be unable to lock files. By contrast, using '_sopen', like I did in the current code, really does make creation of the lock file atomic, and works with any filesystem supported by Windows, including NFS-mounted volumes. So, unless there's a way to do on Posix platforms what '_sopen' does on Windows (perhaps some file-locking feature? I don't know enough about that), I think having 2 completely separate implementations will be cleaner and more maintainable. (Assuming, that is, that we really do want to make file locking so bulletproof.)